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ABSTRACT 

The main r,oal of this thesis is to study the perfor¬ 
mance tradeoffs between parallelism and increased con¬ 
currency control overhead during simultaneous user updates 
of a database. During such updates, a database management 
system must guarantee that the multiple users do not 
interfere with each other. 

The potential advantages of parallelism in accessing 
a database include the better utilization of comouter 
resources and better response times for users. Those 
advantages, however, may be offset by the increased use of 
system resources to irsure that there is no interference 
between the multiple users. Simulation models are used to 
study these two conflicting asnects of concurrency control 
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for both centralized and a d i st r i buted databases. 

One of the most imoortant desigr decisions irvolves 
locking granularity. Locking granularity refers to the 
size and hence the number of locks maintained by the data¬ 
base management system. The centralized database simula¬ 
tion results indicated that in many cases, in particular 
if data access is primarily sequential, coarse granularity 
such as file, relation or record type locking is prefer¬ 
able. However, if all of the updates are small ar.d ran¬ 
domly access the database, finer granularity, such as page 
or record locking becomes necessary. If the sizes ard 
access oatterr.s of updates vary considerably, the simula¬ 
tion results indicated that a lock hierarchy with dif¬ 
ferent siz.ed locks is beneficial. 

In a distributed database, the data is stored or: dif¬ 
ferent computer sites connected through some type of net¬ 
work. In. such a system, some of the database activities 
are local in. that they only involve data at one site. 
Other database activities are distributed in that they 
involve data at several of the computer sites. > In a dis¬ 
tributed database, increased parallelism is possible dur¬ 
ing simultaneous database activities. However, the cor- 
currency control overhead may also ircrease. The simula¬ 
tions modeled a variety of cor currency control algorithm's 
to study the additional tradeoffs in a distributed data- 


In particular, primary site control and decentralized 
control algorithms were simulated. In the primary site 
control algorithms, ore site performs the concurrency con¬ 
trol functions for all of the other sites. In the decen¬ 
tralized control algorithms, the concurrency functions are 
distributed to each of the sites and special provisions 
must be used to prevent or detect deadlock. 

The simulation results indicated that with a high 
speed network and mostly local database activities, either 
concurrency control approach is accentable. As the net¬ 
work becomes slower, the decentralized control algorithms 
are preferable. If most of the database activities are 
distributed, however, the primary site approach can take 
advantage of its "global" knowledge to better schedule the 
processing of transactions and thus provide better perfor¬ 
mance than the decentralized algorithms. 

These results can provide insights into the design 
and implementation of the concurrency cortrol mechanisms 
for a wide variety of centralized and distributed database 


management systems. 
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CHAPTER 1 


INTRODUCTION 

1- PA T ABASE CONCURRENCY CONTROL 

One of the major features of a database management 
system is to allow multiple users access to shared data. 
During such multiple user access (and update), the 
"integrity" of the database must be guaranteed. The 
mechanism which guarantees that "integrity" is commonly 
referred to as the concurrency control subsystem of a 
database management system. 

Two conflicting aspects of the concurrency control 
mechanism affect the performance of a database management 
system. On the ore hand, the concurrency control can 
increase the parallelism allowed in accessing the data¬ 
base. On the other hand, the advantages of such increased 
parallelism may be offset by the amount of system 
resources, or overhead, that are used to irsure database 
integrity. 

The main goal of this thesis is to study the perfor¬ 
mance trade-offs between increased parallelism and 
increased concurrency control overhead ir. order to provide 
insights for concurrency control implementations in 
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database mar: axemen t systems. 

Jr the remain Jer of this ihaoter, some of the prob¬ 
lems i r: database core urrer cy cortrol are di so us sod ar d the 
previous research results or the performance evaluatior of 
cor currency cortrol mechanisms are reviewed. 

2. CON CUR RENCY CONTROL PROBL EMS 

2 .1. Databasie < 2°_ r i?L : '-5^ r: Ly 

The database concurrency cortrol subsystem is resDor- 
sible for the integrity ard cor.sistercy of the database 
during multiple user updates. The following example 
illustrates the type of inconsistencies which can arise 
without concurrency controls. 

One user is producing a summary report of the total 
salaries, taxes and benefits that are paid for a ^iver pay 
period. At the same time some other user is updating 
individual payroll records for the "next" payroll. 
Without some type of concurrency cortrol, the summary 
report may include some data from the "previous" payroll, 
and some from the "next" payroll. Thus, the results of 
that report would rot accurately reflect either the previ¬ 
ous or next payroll periods. 

Furthermore, the report may rot accurately reflect an 
individual's payroll record for either pay period. Sup- 
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pose, for example, that employee x's payroll record was 
beinr, updated. The summary report miqht cortair the rew 
salary but the old tax ard benefit values. 

The concept of "database consistency" refers to the 
permissible states of a database. The states which are 
permissible may require certain relat ionships between 
various elements in the database. For example, one such 
requirement may be that a department salary total must 
equal the sum of all of the individual salaries ir. the 
department. Such constraints are application dependent 
and thus difficult to define for a general database 
management system. 

In. [ESWA76], the concepts of transactions and serial 
schedules are introduced. A "transaction" is a set of 
related atomic actions involving a database which, if run 
alone on a database, preserves database consistency. A 
"schedule" for processing transactions is a sequence of 
atomic actions from the transactions. A "serial schedule" 
is one in which all the atomic actions from one transac¬ 
tion are scheduled first, followed by all of the atomic 
actions from a second transaction, etc. In other words, 
the transactions are run one at. a time aqainst the data¬ 
base . 

A transaction schedule is "serializable" if the 
effects of the atomic actions in the scheduled order are 



!) 

equivalert to rurr ir <» the transactions i p some serial 
schedule. If p,Kh trarsav.-t.ior preserves the cor si store y 
of the database, it is clear that a serial schedule, ar:d 
thus a serializable schedule, must also preserve the cor- 
si storey of the database. 

Two protocols for transaction behavior are defined ir: 
[KSWA761 which are used to insure the ser i a 1 i zabi1ity of 
any schedule. A trarsactior. is said to be "well-formed" 
if all transactions acquire a lock (read or write [DTJK68, 
COURT!]) before touchier, (reading on writin.fi) an object of 
the database. A trarsactior: is said to be " two-pba sed" if 
it acquires all of its locks before releasing any locks. 

If all transactions are two-phased and well-formed, 
[FSWA76] shows that ar.y schedule of atomic actions that 
does rot violate the required locking protocols is serial¬ 
izable and thus preserves the consistency of the database. 

Some database management systems support weaker forms 
of consistency where the applications may allow for cer¬ 
tain violations of the well-formed and two-phased proto¬ 
cols [CRAY7&]. It has also been shown [PFRN7S1 that seri¬ 
alization (or effec tive serializatior ) of trarsactior s is 
sometimes unnecessary. Throughout this study, however, it 
is assumed that the concurrency control subsystems require 
that transactions are we 1l-formed ard two-phased. 



?.?. Deadlock and Rollback 

Those two protocols do provide solutions to some of the 
concurrency control problems. However, other problems 
which the concurrency control subsystem must still solve 
ipclude deadlock resolution arid the problem of cascading 
rollback of transactions. 

A simple example can be used to illustrate the 
deadlock problems. Suppose one transaction locks and 
writes object A and another transaction similarly locks 
and writes object R. Then, the first transaction requests 
a lock on R while the second transaction requests a lock 
on A. The four conditions for deadlock [C0FF71] are met 
since neither transaction can release its existing locks 
without violating the two-phased locking protocol. Thus, 
a concurrency control scheme must solve deadlock problems 
by either prevention or detection and resolution. 

If deadlock detection and resolution is used it may 
be necessary to roll back or undo the effects of a tran¬ 
saction. Note that if locking is not two-phased, some 
other transaction may read the effects of a transaction 
which has beer rolled back. In this case the other tran- 
sactior must also be rolled back. (Otherwise, the updates 
of the rolled back transaction might still appear ir other 
parts of the database). 






This corditior is called "cast adir g" rollback ar.d c ar 


be generated ever if two phased locking is enforced. A 
tran sact i or may also he rolled back because of a change in 
a user's mind, or because of a hardware problem. If that 
transaction had neleased some of its write locks, other 
transactions might also have to be rolled back. To 
prevent this cascading rollback, man v database systems 
hold all locks until the er d of the trnrsactior . 1 r. fact, 
all of the concurrency eortrol subsystems considered in 
this study will require that leeks be held until the end 
of a trar sactior. 

2.3. Database Operating System Corcurrer «._y 

The concurrency control requirements for databases 
are different than the concurrency eortrol requ i remer t.s 
for operating systems. One difference is that an operat¬ 
ing system controls simultaneous access to fixed objects; 
such as line printers, tape drives, specific addresses ir. 
core, etc. A database system, or: the other hard, cortrols 
access to objects whose names arid addresses car change. 

Another difference is that more objects need to be 
locked in a database management system. The database may 
c.ortair milliors of objects, such as records, field 
values, etc., which have to be locked. The number of dif¬ 
ferent objects that car be locked ir an oneratirg system 
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is gererallv much smaller. 

3. PRRV_I_OUS PERFORMANCE R£SIJLTS 

The results of the above problems and consistency 
requirements have resulted in a wide variety of different 
concurrency control mechanisms. The goal of this thesis, 
however, is not to develop new concurrency control algo¬ 
rithms, but to study the affects of various concurrency 
control strategies on the overall performance of the data¬ 
base management system by means of simulation models. 
Previous work in this area can be divided into centralized 
databases, where the entire database is maintained by one 
computer; and distributed databases, where the database is 
distributed across several computers connected by some 
type of network. 

3.1_. C entra lized D ata bases 

In [NAKA75] a simulation model is used to study the 
performance of a database system. A database system model 
and synthetic user application models were run to estimate 
system utilizatiors arid average response times. One 
result observed was that the system bottlenecked due to 
the delays caused by concurrent updates. When the con¬ 
current updates were administratively removed from the 






at>Dl icatior model (to presumably bo rur at r. io.ht) , the 
average respoi se time decreased bv a factor of sever.. 
Sirce rot all appl icatior s allow for administrative vor- 
currer.vy cortrol, it is clear that corc-urrer cv control 
mechar:isms can significantly affect the overall perfor¬ 
mance of the database management system. 

Several other simulation studies have also explored 
the effects of concurrency control or database system per¬ 
formance. In [SPIT76] the effect of scheduling the lock 
requests and releases for the System ?000 database manaq,e- 
rnent system was examined. In that study, the difference 
between locking the database for the entire period of a 
transaction, as opposed to lockino and unlocking the data¬ 
base for each atomic update was surprisingly small. The 
additional parallelism possible with the short locks was 
offset bv the additional time spent by the transactiors 
waiting for that lock. 

In [MUN77] several parameters and concurrency cortrol 
alternatives were explored by means of a simulatior model. 
In that simulatior , alternate methods for chocsin" a vic¬ 
tim in deadlock resolution were explored. The results of 
the simulatior showed t.hat three methods for selecting a 
victim were superior: 1) the victim should be the process 
which accessed the least amourt of data, ?) the victim 
should be the process which hold the fewest number of 
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locks; or 3) the victim should be the process which had 
used the least amount of computer resources. 

In addition to deadlock resolution, the [MUN77J simu¬ 
lation was used to study the optimum number and size of 
the lockable data units in the database. The authors con¬ 
cluded that the units of locking should be very small. 
However, that conclusion was not based on a fixed applica¬ 
tion environment. Instead, the sizes of the transaction 
were made smaller as the sizes of the locks were reduced. 
Thus whether the observed increase in parallelism was due 
to the smaller transactions or the smaller locks is 
unclear. Two other problems with that study were that 
only the CPU utilization was considered and that the CPU 
resources of their model were effectively considered 
in finite . 

In Chapter 2, a simulation model is used to further 
study locking granularity, optimum lock duration and a 
variety of other factors. 

3.2. D ist ributed Databases 

Recently, considerable attention has been devoted to 
the development ard use of distributed databases [LBL76, 
LRL77 , LRL731. In su^h an environment, the data is dis¬ 
tributed across a network of computer systems. The poten- 


_v* . ^ 
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tial benefits of such d 1 st r i but i or- include sharing of data 
across different computer sites, increased parallelism ir 
accessing the database, locatir-g data closer to users and 
increased reliability. 


However, one of the major problems with a distributed 
database is the development of a concurrency cortrol 
scheme to insure database consistency during multiple user 
updates [STON77]. Concurrency cortrol schemes for a cen¬ 
tralized database do rot always extend to a distributed 
database . 

For example, in a centralized database, a transaction 
can request all of its locks at the beginning of its pro¬ 
cessing and release them at the end [CHAM? 1 *]. In this 
scenario, the locks are acquired ir one atomic action. If 
one lock is denied, all locks are denied ard the entire 
lock acquisition step is repeated. Note that in this 
scenario, deadlock is impossible. 


In a distributed database, however, locks may have to 
be obtained at distinct computer sites. Even though the 
lock acquisition at each site is atomic, deadlock can 
still occur because ore processing unit does rot access 
the entire database. Corcurrercy cortrol consideratiors 
require that the different processing units communicate 
with each other. The communication must be used either to 
centralize the concurrency cortrol functions or to prevent 
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or detect a decentralized deadlock. 


Several solutions to the concurrency cortrol problems 
for distributed databases have beer proposed [BERN77, 
ROSE77, GRAY78, MENA73 and STON78]. To evaluate the per¬ 
formance of the different proposals, the number of mes¬ 
sages which must be sent for concurrency control are 
counted. In [BERN77] it is shown that if the transactiors 
are known in advance (i.e. only certain known. types of 
transactions access the database), different types of con¬ 
currency cortrol can be used for different types of tran¬ 
sactions and thereby further reduce the network con¬ 
currency cortrol traffic. 

Unfortunately, a count of overhead message traffic 
does not, by itself, determine the effects of the con¬ 
currency control on the overall performance of the distri¬ 
buted database system. Other factors such as overall sys¬ 
tem load, the amount of non-local processing, and the 
scheduling of transactions must also be considered. 

In Chapter 3, a simulation model is used to examine 
the effects of these factors as well as the effects of the 
message traffic. 

In a distributed database, the same data may be 
stored at several computer sites. These multiple copies 
create additional concurrency control problems in. that the 
copies must be kept mutually consistent during multiple 
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updates. (The simulations ir chanter 7 do rot explicitly 
model the multiple conv update scenarios. However, some 
of the results of the study car be applied to the multiple 
copy update problems.) 

Other studies do directly model the multiple copy 
update problems but do rot address the internal database 
consistency issues. In [GRAP7B1, different algorithms for 
multiple copy cor sistercy are analysed in terms of the 
performance of a distributed database management system. 
In [GARC78], a simulation model is used to compare the 
effects of two algorithms [ALSB7&, TH0M7S1 or the overall 
performance of the distributed database system. Both stu¬ 
dies show that under a wide variety of assumptions a "pri¬ 
mary copy model" is better for maintaining multiple copy 
consistency. The primary site model basically implies 
that the control of updates to the different copies is 
channelled through a single or primary copy of the data¬ 
base. 

n. OVERVIEW 

This thesis will analyze the effects of concurrency 
control or the performance of both centralized and distri¬ 
buted databases. In. both cases, simulatior models are 
used to study the tradeoffs between increased parallelism 
and increased locking overhead. 
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One parameter of primary interest is the locking 
granularity. Locking granularity refers to the size of a 
lockable unit or granule which covers a portion of the 
database. Locking granularity car. be extremely fine (i.e. 
one lock is associated with each sector of a disk). Or, 
locking granularity could be extremely coarse (i.e. one 
lock is associated with each disk drive). 

In Chapter 2, ar, extensive simulation, model is 
presented which explores a large class of concurrency con¬ 
trol alternatives. The model is parameterized to provide 
insights into the locking parameters for a wide variety of 
database systems. The simulation experiments study lock¬ 
ing granularity, the overhead costs of locking, the tran¬ 
saction types and sizes, a locking hierarchy, and the 
times when locks are acquired. Most of these results have 
been published previously [RIES77, RIES791. 

In Chapter 3, the simulation models are extended to 
distributed database systems. These experiments study the 
effects or: performance of locking granularity, four dis¬ 
tributed concurrency control algorithms, the transaction 
types ard sizes, and various network related parameters. 

In Chapter '1, the major results these studies are 
summarized and several directions for future research are 


suggested. 


CHAPTER 2 


CENTRALIZED DATABASE SYSTEMS 


1- INTRO DUCTION 

In order to insure the consistency conditions dis¬ 
cussed in. chapter 1, a variety of concurrency control 
mechanisms [CHAM7^, C0DA71, ESWA76, GRAY75, GRAY76, 
MACR76, STEA76, ST0N7N ] have been proposed and implemented 
in single machine database management systems. In this 
chapter the performance issues of these types of mechan¬ 
isms are examined. 

Clearly there are advantages to increasing the paral¬ 
lelism in processing transactions. Unfortunately, the 
price of this increased parallelism is the increased over¬ 
head which must be expended to achieve it. The goal of 
this chapter is to study the tradeoff between these con¬ 
flicting performance considerations on a single machine 
database management system. 

In section. 2, a simulation model is developed to 
study that tradeoff. In sectior 3, the results of experi¬ 
ments with that simulation model are reported. In addi¬ 
tion, two extensions to that 


model are used to study 
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alternate i-or.c urrertv cor trol mechar i sms . Fir ally, the 
major corclusicr s are summarized in section ! J . Ir. the 
remainder of this section , the performance issues ar.d 
approaches of centralize! corcurrercy cortrol are 
rev iewed. 

1.1. Per formerce Issues 

An evaluation of concurrency control must include an 
analysis of the tradeoffs between the overhead spent or. 
locking versus the advantages of allowing more parallel 
access to the database. The advantages of increased 
parallelisms are in terms of better user resoor.se time and 
increased machine uti1ization. 

The amount of overhead spent or: locking is deoerder.t 
on several parameters of the concurrency control mechan¬ 
ism. These parameters include the size of a lockable 
unit, the costs of setting and releasing locks, the pro¬ 
portion of resources required for locking and the length 
of time for which the locks are held. Each of these 
parameters is considered in turn. 


Mia 
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1.1.1. Loc kir g Granularity 




All of the corcurreri v cor trol mechanisms involve the 
locking of some physical or logical portior of the data¬ 
base. The smallest portior of the database which can be 
locked is referred to as a "granule". The size of a 
granule varies in. different database management systems. 
In some systems (CODASYL [CQDA731, System R [ASTR76 ] , 
DMS-1100 [GRAY7S]) the granule may be as small as ore 
record. Other systems (Svstem 2000 [SPIT76], IMAGE 

[HEWL771) support one granule covering the entire data¬ 
base. Still other systems (DBMS-11 [DEC77 ] , LSL [LIPS76]) 
support intermediate sized granules such as files or 
areas. 

There is a clear tradeoff between locking overhead 

** .. 

and parallelism based on the locking granularity. Fine 
granularity allows a higher degree of parallelism at 
greater cost in managing locks. For example, assume that 
a granule corresoords to a reccrhd in a database. Then the 
transactions may run in parallel without corflict as lorg 
as they access distinct records. However, the database 
system must be prepared to handle as many locks as there 
are records in the database. 

Coarse granularity, on the other hand, inhibits 
parallelism but minimizes management of locks. If the 
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granule is ti.r siiere I the er. tir<> database , r trar cat. tier r. 
will cur in parallel . The dnt. »ha sy si k^epr tr ru k of 
only ore 1 oek . 

Different sized granules can he suenor Led ir a look 
hierarchy [GRAY76J. Ir. a lock hierarchy, a tree structure 
of locks is supported. A transaction car. either- expli¬ 
citly hold leeks on lower branches of the tree, or impli¬ 
citly hold those locks by explicitly locking an ancestor 
node common to all of the lower branches. 

With such a hierarchy, the costs of locking for large 
trar. sac tior s may be greatly reduced since it is cheaper to 
set one large look than to set many small locks. However, 
the locking costs for the trar sac ti or. s using small locks 
may increase. Those transactions would have to set all 
the locks in. the path from the leaves to the root of the 
tree. Again a tradeoff is observed between the parallel¬ 
ism allowed and the locking overhead. 

For example, consider a two-level hierarchy where one 
loc k at the top level cortrols access to the or tire data¬ 
base and many (more than ore) locks at the lower level 
control access to individual "parts" of the database. A 
transaction which accesses the entire database car 
exclusively lock the one top level lock. Without a lock 
hierarchy and just the small locks, it would be much more 
expensive for that transaction to lock all of the small 



locks . 


The above lock hierarchy, however, increases the 
locking overhead for the transaction which just access ore 
"part" of the database. That transaction must set the 
higher-level lock in an "intention" mode [GRAY76] (imply¬ 
ing that explicit locking is required at the lower level) 
and still lock the individual part of the database. Thus, 
that transaction sets two locks. Without a lock hierarchy 
and just the small lock, that transaction would set only 
one lock. 

h 1.2. 

Concurrency control overhead refers to the amount of 


computer 

resources 

utilized by 

the 

locking 

mechanism. 

This "overhead" can 

be 

thought 

o f 

as the 

difference 

between 

the resources 

required 

by 

a transaction in a 


multi-user system and the resources that would be required 
if the transaction, could be run as the only user of the 
database. The locking mechanisms must comoete with the 
transactions for memory, CPU cycles, and I/O channels. 
Thus, as a locking mechanism increases in complexity and 
requires more resources, it will start to interfere with 
the running of the transactions. 


The ratio of resources spent for locking to resources 
spent for processing transactions is critical. For exam¬ 
ple, a ratio of one implies that it is as expensive to 
lock a granule as it is to process the data in that 
granule. In this case, two transactions could have been 
run without locking in the time it takes a transaction to 
set its locks, process the data, and release the locks. A 
less expensive concurrency control which only allowed half 
of the parallelism might provide the same throughput. 

2-1.3. L ock Durat ion 

Another factor which affects the degree of parallel¬ 
ism and the cost of concurrency control is the time period 
for which the locks are held. Two simple procedures which 
insure that a transaction is two-phased (See Chapter 1) 

are: 

1) set all locks at the beginning of a transaction or 

2) hold all the locks until the end of a transactior . 

If the secord option is chosen, the locks can still 
be preclaimed as in option 1 or requested and granted as 
needed by the transaction. 

A performance tradeoff is again possible. By not 
locking resources until they are required, additional 




parallelism is possible. However, the locking overhead 
costs are increased by two factors. First, the con¬ 
currency control mechanism must check for deadlock 
[C0FF71]. Second, if deadlock is detected, a transaction, 
may have to be restarted. The resources already used by a 
restarted transaction should also be included as overhead 
costs since they would not have been used if the transac¬ 
tion was run by itself. 

In summary, the important performance parameters are 
locking granularity, locking overhead, and lock duration. 

1_.2. L ocki ng !^ e _ c l 2 £!lisms 

Two general options have been proposed for single 
machine concurrency control -- physical locks and predi¬ 
cate locks. 

1.2.1. Physical Locks 

Physical locks are placed or records, pages, seg¬ 
ments, files, areas or the entire database. Ir. this case, 
a "granule" refers to a physical portion of the database. 

With physical locks, a data manipulation command can¬ 
not proceed if a granule it needs is locked by someone 
else. Various strategies for requesting and releasing 








locks have beer: suggested [CilAHT'l, GRAY76, STEA76, 
MACR76]. Some of these strategies require the detection 
resolution of deadlock. 

The basic idea behind physical locking; is straight 
forward. If a transaction needs to read a portion of the 
database but not write it, a read or shared lock must 
first be obtained on a granule which physically covers 
that portion of the database. Other transactions which 
also read that portion or a portion covered by the same 
granule can share that lock. 

If all or a portion of the granule is to be updated, 
an exclusive lock must be obtained which cannot be shared 
by other running transactions. The two-phase requirement 
insists that no locks can. be released until the transac¬ 
tion has acquired all of the locks that it needs. 

1.2.?. P red icate Locks 

A predicate lock can be set or. the exact portion of 
the database which is to be accessed. The portion of the 
database which is locked is determined by predicates or 
qualifications associated with the transaction . The 
predicate (i.e, "all records with date field values in 
June, 1976") restricts the transaction to a logical subset 
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of the database. Such locks do not necessarily correspond 
to ary physical portion of the database. This approach is 
explored in [FLOim, STONT'l , ESWA76]. 

In predicate locking, a predicate corresponding to a 
selection criteria of a transaction is submitted to the 
locking mechanism. If the locking mechanism can "prove" 
that a transaction does not conflict with any running 
transactions, the locks are granted. Otherwise, the 
requesting transaction, must wait. A propositional logic 
"theorem prover" can be used to prove that two transac¬ 
tions do not conflict. The sophistication of the theorem 
prover can be varied depending on the tradeoff between 
increased parallelism and CPU recourses used for locking. 

The granularity in. predicate locking also varies. 
For example, a predicate such as "employee_ro=123^" might 
restrict the transaction to one record. On the other 
hand, a predicate such as "departmert=ergineering" might 
represent hundreds of records. Notice that predicate 
locks, like physical locks, can be acquired throughout the 
duration of a transaction. 

Predicate locking has two obvious advantages. One is 
that a predicate lock can accurately describe the exact 
logical portion of the database that is to be accessed by 
a transaction. The second is that the cost of setting 




such a lock depends on the number of simultaneous transac¬ 
tions actually submitted and not or the amount of data 
that is actually accessed. 

However, the predicate locking mechanism may need¬ 
lessly keep a transaction from running. Suppose the 
predicate "AGE>29" has been granted a lock for a running 
transaction and that another transaction issues the 
request "AGE<31". If no one with AGE =30 were in the data¬ 
base, both transactions could be allowed to run. But the 
predicate locking mechanism would require that the second 
transaction waits. 

Thus, predicate locking may reduce corcurrercy con¬ 
trol overhead at the expense of allowing less parallelism 
in accessing the database. 

2. model descri ption 

A simulation model is used to investigate the tra¬ 
deoffs between concurrency control overhead and increased 
parallelism. The model is described by first explaining 
the flow of transactions around a closed-loop model. Next 
the model input and output parameters are discussed. 
Finally, the allocation and competition for resources in 
the model are described. 






2. K T ransac tion Fl^ow 

The running of transactions against a database is 
simulated by assuming there are a fixed number of transac¬ 
tions which are cycled continuously for TMAX time units 
around the model shown in figure 2-1. A transaction goes 
through the following steps: 

1) Arrive on the pending queue 

2) Acquire locks 

3) Process I/O requests 

4) Process CPU requests 

5) Release locks 

6) Generate a new transaction and return to step 1 

These steps are explained in more detail below. 

Initially, the transactions arrive ore time unit 
apart and are placed on the pending queue. The transac¬ 
tion is removed from the PENDING queue and all required 
locks are requested. If the locks are granted, the tran¬ 
saction is nlaced or. the bottom of the I/O queue. If the 
locks are denied, the transaction is placed on the bottom 
of a RLOCKED queue. The blocking transaction is recorded. 
(The description of which locks are required by a 















transaction is giver in section 2.3.) Note that no locks 
are held while or the blocked queue so deadlock is impos¬ 
sible. 

After completing the I/O required, the transactior: is 
placed or the bottom of the CPU queue. 

After completing the CPU required, the transaction 
releases its locks. At this point a new transaction is 
added to the end of the PENDING queue. (Note that each 
transaction goes through one I/O phase and one CPU phase. 
Although they are sequential in. the model, the result 
would be the same if each transaction were to go through 
many I/O - CPU phases in a single cycle.) All transactions 
that were blocked by the completed transaction are placed 
on the front of the PENDING queue. 

2.2. Mo de l Para meter s 

The input parameters can be divided into those that 
characterize the workload , and those that characterize the 
system. Workload Darameters describe the database and the 
transactions that are run against that database. System 
parameters describe the computer system and/or the data¬ 
base management system characteristics. The output param¬ 
eters character i ze the throughput, overhead and utiliza¬ 
tion of the system. These parameters are all described in 
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more detail below. 


2.2.1. Workload Parameters 

The workload input parameters are summarized in Table 
2-1. The number of transactions, NTRAN, in the system is 
fixed. The closed loop model could have two interpreta¬ 
tions. As each transaction completes, the user submits 
another transaction. Alternately, the transactions could 
be viewed as application programs. When one of these com¬ 
pletes, another application program enters the system to 
take its place. 

The database size, DBSIZE, refers to the number of 
entities in the database. In this model, the database is 
an abstract collection of entities. An entity can be 


Table 2-1 Workload Parameters 


Parameter 


Description 


NTRAN 

DBSIZE 

RAD 

AMEAN 

BMEAN 


ALPH 

LKPLMT 


number of transactions 
number of entities in the database 
a transaction size parameter, 
mean for exponential distribution 
of transaction size. 

another mean for exponential distribution 

of transaction size. Used with AMEAN for 

hyper-ex do nential distribution 

of transaction sizes. 

cut of proportion between AMEAN 

and BMEAN. 

lock placement assumption (see below) 
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thought of as the unit of data moved by the operating sys¬ 
tem into the database system buffers. 

In the simulation, three types of distributions for 
transaction sizes are used. The size of a transaction 
refers to the number of entities, ME, touched or accessed 
by a p,iven transaction. The number of entities "touched" 
or accessed by a Riven transaction completely determines 
the amount of I/O, CPU and lock resources required by that 
transaction. In. the simplest case, the sizes of the tran¬ 
sactions are uniformly distributed by the RAD parameter. 

i. u 

The number of entities touched by the 1 transaction is 
Riven by: 


NE i = i*RAD, forisl.NTRAN 

This distribution reflects a workload with a uniform mix 
of different sized transactions. 

The second distribution of transaction sizes is 
exponential. The average transaction size is determined 
by the AMFAN parameter. In this case, 

NE^=-AMF.AN*loR(rrd) 

where rnd is a uniformly distributed random number between 
zero and ore. This distribution reflects a workload where 


most of the transactions are small a very few transactions 
are 1 a r r e . 





The final distributior used is hyper-ox do rer-tia 1 with 


three parameters, A FT A N , RHEAN, or d ALPH. Ir: this distri¬ 
butior, some (ALPH x 100 percent) of the transactiors have 
sizes which are exponentially distributed with a sear of 
OMF.AN. The other transactions- have sizes which are 
exponentially distributed with mean AMEAM. In this case, 

NE i =-BMEAN*lorT(rnd1 ) 

if rnd2 < ALPH or 


NE^=-AMEAN*log(rnd1 ) 

if rrd2 >= ALPH 

where rndl, and rrd2 are independent random varia;les 
similar to rrd. This distribution is used to model 
scenarios where, for instance, most of the transactions 
are extremely small and only touch a few records or cages 
of a database, while a few transactions must access a very 
large number of records. Note that the exponential dis¬ 
tribution is just a special case of the hyper-exporertia 1 
distributior with an ALPH of zero. 

The lock placement parameter, LKPL^t, determines the 
number of locks that a giver: transaction requires. Three 
different assumptions regarding lock placement are simu¬ 


lated . 





With "well placed" locks (LKPLMT = 1), the number of 
locks required by a giver trarsactior is exactly propor¬ 
tional to the percentage of the database touched or 
accessed by the transaction. For transaction i, the 
number of locks, NL, is 

NL.=CEILING(ME i *MGRAN/DBSI?.E) 

where NGRAN is the total number of locks available. 
Hence, a transaction which touched half of the entities in 
the database would require half of the possible database 
locks. Note that this amounts to assuming that the 
granules are "well placed", i.e. that the entities needed 
by the transactions are packed into as few 'lockable' 
granules as possible. This assumption is reasonable for 
transactions which access the database sequentially. 
Although sequential processing in database applications 
has been observed [RODR76], actual transactions may 
require a combination of sequential and random accesses to 
the database. 

Under a "worst case placement" assumptior (LKPLMT = 
2), each trarsactior requires the maximum number of 
granules possible. In this case 

NL.=MIN(NE. NGRAN). 

1 1 » 
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If the total number of entities touched by n giver trar.- 
sactior , NR, is greater than the number of looks cover in r, 
the entire database, NGRAN, then in the worst case, all of 
the locks might have to be acquired in order to access the 
needed entities. If NE is less than NGRAN, the number of 
locks that have to be set is bounded by the number of 
entities, NE. Thus, the number of locks required is the 
minimum of the number of locks for the entire database and 
the number of entities touched by the transaction. This 
assumption simulates an "unccoperative M transaction , i.e. 
one whose access pattern is the worst possible from the 
lock mechanism point of view. This scenario is the oppo¬ 
site extreme of the "well placed" assumption. 

Under a "random access placement" assumption, a 
mean-valued formula is used to estimate the number of 
locks required for each transaction. The number of locks 
required under this assumption is analogous to the number 
of blocks accessed when randomly selecting records from a 
blocked file. The formula for this number and its deriva¬ 
tion are given in [YA0771. This model accurately reflects 
random processing where the probability of accessing arv 
entity is the same and independent of any previous enti¬ 
ties accessed. Let DRSIZE be the number of entities in 
the database, NGRAN be the total number of locks, and p be 
the number of entities per lock ( = DBS 1 7. E/NG R A N ) . Then a 





32 


transaction which accesses NE entities requires 


NCRAM * 


1 - 


r DRSIZE-p 

Se 

"DRSIZ E 
C NE 


T , . -DBSIZE-p . „DBS IZ E 

The expressions C^p and represent 


locks 

the number of different ways ME entities can be selected 
from DBSIZE-p and DBSIZE entities respectively. The 
derivation of this formula is identical to the derivation 
in [YA077] and is not repeated here. 


2.2.2. Sys tem P ar ameters 

The system parameters are listed in Table 2-2. The 
number of granules, NGRAN, into which the database is 
divided is varied from one to the number of entities in 
the database, DBSIZE. A granule is the unit which is 
locked by a transaction. Each granule is assumed to be 
the same size. Hence, if NGRAN = 1, a granule is the 
entire database of DBSIZE entities. If NGRAN = 2, a 
granule is DBSIZE/2 entities. If NGRAN - DBSIZE, each 
granule is 1 entity. 


The CPU costs for processing a transaction are deter¬ 
mined by the CPURATE parameter. The CPURATE refers to the 
CPU resources required for processirg ore entity of the 
database where CPU resources are in time units of the 


i hi rfiatfri «'i*li— 






Table 2-2 System Parameters 


Parameter 


Description 


NCRAN 

CPURATE 

10RATE 

LCPURATE 

LIORATE 

IOOVLP 


number of lockable granules 
CPU time to process ore entity 
I/O time to process ore entity 
CPU rate to process one lock 
I/O rate to process ore lock 
number of simultaneous I/O 
operations permitted 


simulation. Note that these are the resources 


for pro¬ 


cessing the transactions and do rot include any costs for 


processing the locks. 


Similarly, the I/O costs for processing a transaction 
are determined by the IORATE oarameter. Note that the 
CPURATE and IORATE could have also been, considered as 
workload parameters because in many cases they are appli¬ 
cation dependent [HAWT79]. 


The lock CPU parameter, LCPURATE, refers to the CPU 
resources required to request (and set/release) a lock for 
one granule. 


Similarly, LIORATE determines the I/O overhead for 
setting one lock. For some DhMS systems, lock tables are 
kept entirely ir: main memory. These systems are modeled 
by a LIORATE of zero. On the other hard, a database sys¬ 
tem which has as many locks as pages in the database, may 
have to keep lock tables or secondary storage devices. 
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Such systems would have a nor-zero LIORATE parameter. 

The I/O overlap, IOOVLP, indicates how many simul¬ 
taneous I/O operations are possible. This parameter is a 
surrogate for the number of independent paths used between 
main memory and secondary storage (and hence for how much 
I/O activity can go on in parallel). 

2.2.3. O utp ut Parameters 

The performance measurements shown in Table 2-3 are 
generated by each simulation run. The total CPU time, 
TCPU, refers to the number of time units in which the CPU 
is busy. During TMAX - TCPU time units the CPU is idle. 


The total I/O units, TIO, is the number of time units 
in which the I/O resources are busy. The total I/O units 
utilized can become larger than TMAX if the I/O overlap 


Table 2-3 Output Parameters 


Parameter Description 


TCPU 

TIO 

LOCKCPU 
LOCKIO 
USEFULC P(J 
USEFUL 10 
TRANCOM 
AVERRES 


Total time CPU active 
Total time I/O active 
CPU overhead for locking 
I/O overhead for locking 
CPU time for transactions 
I/O time for tran sactiors 
number of transactions completed 
average response time 
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parameter is greater than 1. In fact TIO is bounded above 
by TMAX * IOOVLP. 

The CPU units used for lock management are recorded 
in LOCKCPU while the I/O units used for locking are 
recorded in LOCKIO. 

The useful computer utilization, USEFULCPU and USEFU- 
LIO, refer to the net resources used for transaction pro¬ 
cessing. These measurements reflect the transaction pro¬ 
cessing time without the concurrency control overhead. 
Note that 

TCPUrLOCKCPU+USEFULCPU 

TIO=LOCKIO+LOCKCPU. 

The total number of transactions completed at the end 
of a simulation run, TRANCOM, and the average response 
time, AVERRES, are also recorded. The time when each 
transaction is first placed or the pending queue is con¬ 
sidered an arrival time for that transaction. The differ¬ 
ence between that time and the time when that transaction 
releases its locks is called the response time. Some 
transactions may have started but not finished at the com¬ 
pletion of the simulation, run. These transactions are not 






included in the computation of TRANCOM or AVERRES. 


2.3. R esource Alloca tion an d Usar,e 

The above parameters completely determine the 
resources required by each transaction. These resources 
are summarized in Table 2-4. 


The CPUTIME represents the total number of time units 
that a transaction would be on the CPU queue if it were 
running by itself. However, if there are N transactions 
on the CPU queue, the CPU is multiplexed amort* those N 
transactions. For example, if there are always 2 transac¬ 
tions on the CPU queue, a transaction with a CPUTIME = 50, 
would remain on. the CPU queue for 100 time intervals. 


The IOTIME is similar, except for the effect of the 
IOOVLP parameter. If there are N transactions on. the I/O 
queue, each transaction. progresses min. ( 1 ,100VLP/N ) time 

Table 2-4 A Transaction 


RESOURCE 


FORMULA 


NE 

NL 

CPUTIME 
IOTIME 
L0CKI0TIME 
LOCKC PUT I ME 


= furetion(RAP) 

or function(AMR AN , RMEAN , ALPH) 

= function(NE , LKPLMT, DBSIZE) 
= NE * CPU RATE 
= NE * IORATE 
= NL « LI OR ATE 
= NL * LCPURATE 









units. The progress is bounded above by 1 to simulate ore 
transaction having only ore outstanding I/O request at a 

time. 


The locking mechanisms are giver a higher priority 
for the I/O and CPU resources than the active transac¬ 
tions. Also rote that these costs are repeated each time 
a transaction requests its locks. For example, suppose a 
transaction requests locks, they are denied, and the tran¬ 
saction is placed on the blocked queue. Later that tran¬ 
saction. is removed from the blocked queue, the locks are 
requested again, and this time they are granted. The 
total lock overhead associated with this transaction is 
twice NE times the lock rates. 

Two approaches are used to simulate the competition 
for the available granules. Under both approaches, the 
decision to grant or deny a lock request is based on 
another uniformly distributed random variable, rrd3. 

Under one approach, the granules for each transaction, 
are considered to be completely uncorrelated. Let CRL be 
the number of locks currently held by the active transac¬ 
tions. Then a transaction needing NL locks, has those 


locks granted if 
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NGRAN-CRL 

S L NL 
rrd3 > 

Sl 

The above expression is simply the number of ways of 
choosing NL locks from those that are already still 
unclaimed divided by the number of ways of chosen the NL 
locks from all of the locks. 

Under the well-placed lock assumption, the above for¬ 
mula actually penalizes finer granularity. For example, 
doubling the number of locks, (2 * NGRAN), could result in 
also doubling NL and CRL. The number of locks for a tran¬ 
saction, NL, would be doubled if a transaction touched all 
of the entities covered by a given lock. But then, the 
probability of a successful lock request is actually 
smaller due to the finer granularity because 

2*NGRAN-2*CRL NGRAN-CRL 

L 2» NE __ _NE__ 

r 2*'NGRAN " r NGRAN * 

L 2*NE U NE 

The right hand side is the probability of obtaining NL 
locks with the original granularity while the left hand 
term is the same probability if the number of locks were 
doubled. 

To avoid this bias under the well-placed lock assumc- 
tion, a second approach to computing lock conflicts is 
used. With this approach it is assumed that the first 
requested granule is uncorrelated with any of the granules 


v 


which are already locked. Fur therrnore, the additioral 
requested granules are assumed to be distinct from the 
already locked granules. Under this assumption, the locks 
are granted if 


rnd3 


_ CRL__ 

(NGRAN-NK+TT' 


Under either approach, if the locks are granted, CRL 
is incremented by NL. If the locks are denied, one of the 
active transactions is picked as the blocking transaction. 
The probability that a transaction, say Tj is the blocking 
transaction is NL./CRL; i.e. is directly proportional to 
the number of locks held by the blocking transaction. 


3. RESULTS and DISC USSI ON 

In this section the results of running the simulation 
under a wide variety of parameter settings are reported. 
First, the results of some initial runs of the simulation 
are explained. Next the effects of varying the workload 
and system parameters are reported. Finally, the effects 
of two changes to the basic simulation model are 


described. 
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3.K An Initial Scenario 

The simulation is initially run with the workload 
parameters shown in Table 2-5 for 10,000 (TMAX) time 
units. The system parameters for the first run are shown 
in Table 2-6. 

In this scenario, ten transactions were submitted to 
a database of 5000 entities. The transactions required 
from 50 to 500 entities each (initially the sizes were 
uniformly distributed). (The simulation was also run with 
up to 20 transactions with no appreciable effect other 
than scale on the output parameters.) 


Table 2-5 Sample Workload Parameters 

Parameter Value 

NTRAN 10 

DBSIZE 5000 

LKPLMT Well-Placed 

RAD 50 


Table 2-6 Sample System Parameters 
Parameter Value 


NCR AN 

C PU RATE 

IORATE 

LCPIJRATF. 

LIORATE 

IOOVLP 


1 to 5000 
.05 
.20 
.01 
.20 
1 





The locks were assumed to be "well-placed" with 
respect to the accessing transactions and thus the tran¬ 
sactions required the smallest number of granules that 
were required to "cover" the touched entities. 

The I/O overlap parameter was set to one which 
results in orly ore transaction processing an I/O opera¬ 
tion at ore time. Note that for this run the I/O rate is 
four times the CPU so that this simulates an "I/O bound" 
application. The CPU cost of a lock was 1/5 that required 
to process an entity. Lastly, the I/O cost of a lock was 
equal to the I/O cost of an entity. Hence, this initial 
run simulated a lock table being kept or secondary 
storage. 

Intuitively, these input parameters could be inter¬ 
preted as followes: 

DBSIZE is 5 million bytes (ore entity is 1024 bytes) 

Average transaction accesses 250,000 bytes of data. 

IORATE of 30 msecs per entity (ore disk accesses). 

CPU RATE of 7.5 msec per entity. 

LIORATE of 30 msecs per lock. 

LCPURATE of 1.5 msecs per lock. 

In this interpretation ore time unit corresponds to 150 


mil 1iseconds . 
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For these simulation rurs, the value TMAX = 19000 was 
chosen after running simulations for various smaller 
values including TMAX = 2500. In all cases, no change 
(except for scaling) was observed in the output parameters 
between TMAX = 2500 and TMAX = 10000. For some of the 
experiments discussed later, other values of TMAX were 
required to guarantee convergence. Keeping the other 
parameters fixed, the number of granules was varied 
between 1 and 5000. The output from the simulations is 
presented in Tables 2-7 and 2-8. 


Note that the utilization of I/O resources for tran¬ 
saction processing, USEFULIO, peaked at 40 granules. 
Within }% of this value was reached with only 10 locks. 
The useful 1/0 remained relatively constant until the lock 
I/O costs start to be a significant fraction of I/O time. 
For a small number of granules, high lock I/O cost 
resulted from lock conflicts which generated still more 
lock I/O. (In an actual implementation of a locking 
scheme, a small number of locks could easily be maintained 
in primary memory. This alternative is explored subse¬ 
quently.) Similai iy, the useful CPU time peaked at 30 
granules, ard again this value was almost reached (within. 
1%) with as few as 10 granules. These results are por¬ 
trayed graphically in figure 2-2. The lock CPU costs were 







puter utilization 
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Table 2-7 

CP'i ar.d I/O Utilization 
Initial Scenario 


NO of_GRA NUL5‘5 

USEFULIO 

USFFULCPU 

LOCK 10 

LOCKCPU 

1 

7041.957 

1759.906 

1282.000 

12.820 

2 

8376.933 

2091.914 

970.000 

9.700 

3 

9002.256 

2237.415 

777.000 

7.770 

4 

9030.253 

2258.925 

671.000 

6.710 

5 

9273.915 

2304.927 

604.000 

6.040 

7 

9433.514 

2309.940 

474.000 

4.740 

9 

9449.087 

2337.442 

428.000 

4.280 

10 

9476.130 

2324.941 

437.000 

4 . 370 

15 

9425.585 

2358.445 

403•000 

5.210 

20 

9437.987 

2354.943 

396.000 

5.280 

30 

9534.303 

2377.449 

371.000 

6.720 

40 

9572.718 

2354.949 

360.000 

7.900 

50 

9504.073 

2339.950 

360.000 

8.790 

75 

9448.435 

2332.452 

454.000 

13.290 

100 

9378.277 

2324.951 

482.000 

15.430 

125 

9351 .744 

2316.457 

547.000 

20.890 

150 

9304.128 

2279.960 

613.000 

23.700 

200 

9159.688 

2259.959 

753-000 

30.000 

250 

91 10.531 

2249.964 

806.000 

36.740 

300 

8768.228 

2177.465 

1015.000 

43.470 

500 

8517.211 

2097.466 

1390.000 

69.499 

750 

7820.61 1 

1919.974 

1950.000 

94.439 

1000 

7359.828 

1814.976 

2462.000 

128.099 

2500 

4764.175 

1 1 89.989 

4824.000 

241.199 

5000 

3408.635 

824.992 

6120.000 

305.998 


minimized with 10 granules. With fewer granules, the 
request failure rate caused enough re-requests for locks 
that the overall CPU costs for locking increased. With 
more than 10 granules, the reductior in lock request 
failures did rot offset the costs of setting the addi¬ 
tional locks required for each tran saction . 
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Table 2-8 

Transaction throughput mensurener: ts 
Initial Scenario 

AVERAGE 


N0_of GRANULES 

RESPONSE 

TIME 

COMPLETED 

1 

751 .914 

1 28 

2 

557.232 

168 

3 

534.399 

178 

A 

523.OR? 

182 

5 

490.297 

195 

7 

506.667 

1 89 

9 

515.117 

188 

10 

472.330 

202 

15 

4 84.21 4 

1 96 

20 

462.678 

208 

30 

472.732 

205 

A0 

454 . 189 

212 

50 

441 . 537 

218 

75 

430.543 

223 

100 

4 2 0.4 1 6 

231 

125 

463.255 

208 

150 

460.429 

210 

200 

435.748 

222 

250 

504.021 

192 

300 

447.065 

215 

500 

472.088 

204 

750 

570.089 

168 

1000 

546.023 

175 

2500 

815.784 

1 15 

5000 

1054.988 

36 


The average resporse time and the total number of 
transactions completed at time TMAX reached extremums at 
100 granules. With this number of granules, the smaller 
tran saction s requiring less resources were able to rur. to 
completion. Thus, a 'shortest job first’ property was 
observed. Moreover, with finer granularity (>200 
granules) locking overhead actually increased the average 
resporse time. In these cases the higher I/O locking 
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overhead (753 to over 6000 time units) delayed the normal 
processing of transactions. 

In summary, urder the initial scenario parameter set¬ 
tings, the useful computer utilization increased as the 
number of granules increased then leveled off and fell. 
Moreover, the maximum utilization occurred with a rela¬ 
tively small number of granules and that utilization was 
within 1% of that optimum for 10 granules. The conclusion 
can be drawn that crude locking schemes with coarse granu¬ 
larity were nearly optimal. Since a crude locking system 
may be easier to implement than a sophisticated finer 
granularity scheme, it may be preferred. 

For this case, response time, and throughput were all 
better with a small number of granules. Hence, a large 
number of granules (such as would be required to lock disk 
sectors or individual records) may be inappropriate. 

— However, changes in the parameters and simulation 
model do alter these observations. In the rext section., 
the effects of alternate workload parameters are reported. 
In section 3-3, the systems parameters are v ar ied. In 
section 3.4, the effects of two extensions to the model 


are reported. 



3.2. Effects of Workload Parameters 

Charges in the workload parameters would reflect 
charges in the characteristics of the aoplicatiors which 
were running or the system. It has been noted already 
that the number of transactions had little effect or the 
observed output parameters. Other workload parameters did 
make some difference or the optimum granularity. The 
major difference was due to the lock placement assump¬ 
tions. Other workload parameters tested included changes 
in transaction, sizes, changes in database sizes and the 
addition of an idle time period for the transactions. 

3.2.1. Plac emen t of Locks 

In the previous experiments the locks were assumed to 
be well-placed. The other two placement assumptions were 
also tested. In the worst case assumption, each transac¬ 
tion required the maximum number of granules possible. In 
the random placement assumption, the probability of 
accessing any entity was identical and indeper:dent of any 
previous entities accessed. 

Which model is chosen affects the previous observa¬ 
tions. If the "worst case" is chosen, the following 
intuitive analysis applies. In figure 2-3 it is assumed 



that all transactions touch the seme number of entities, 
NE. The machine utilization measures would decrease as 
the number of locks for the entire database increased from 
or.e to NE. The decrease is because each transaction would 
require more locks thus increasing the locking overhead. 
However, there would be no additional parallelism because 
each transaction locked the entire database. 

The utilization would increase, however, as the 
number of locks increased from NE to the total number of 
entities in the database. In this case, the cost of the 
locking overhead would remain constant while the allowed 
concurrency increased. The locking overhead would remain, 
constant since each transaction could never set more than 
NE locks. 

Consequently, the optimum number of locks would be 
very dependent on. the transaction sizes in the worst case 
placement lock assumption. Moreover, it would always 
occur at 1 granule or the maximum number of granules 
(corresponding to ore lock per entity) if all the transac¬ 
tions were the same size. The effects of having varying 
transaction sizes will be discussed below. 

The simulation model was run for each of the three 
placement assumptions under a wide variety of parameter 
settings. Figures 2-'i and 2-5 diagram some of the 
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results. In figure 2-4, the transaction sizes were deter¬ 
mined by an exponential distribution with a mean value of 
500 entities (10% of the database). In figure 2-5, the 
transaction sizes were also determined by an exponential 
distribution but with a mean value of 5 entities (0.1% of 
the database). For these runs, the locks were assumed to 
be in main memory (no lock I/O required) and the I/O and 
CPU time required by the tran sactions were equal. These 
conditions were chosen as the ores most favorable to finer 
granularity. The other parameters were identical to those 
described in the initial scenario, with one major excep¬ 
tion. In figures 2-4 and 2-5, the random lock conflict 
assumption is assumed for all three placement conditions. 
Under the random lock conflict assumption, the granules 
associated with each transaction are considered to be com¬ 
pletely uncorrelated. This modification is made primarily 
for validity checking. With the same lock conflict assump¬ 
tions, the end points (1 and 5000 granules) should and did 
result in identical simulation runs under the three lock 
placement assumptions. 

The top curves in both figure 2-4 and 2-5 were con¬ 
sistent with the results of the initial scenario. The 
bottom two curves renresent the worst case and random 
access assumptions. 
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For large transactions requiring about 10% of the 
database (see figure 2-4) a smaller number of granules was 
still to be prefered to a lock tor each entity. For small 
transactions requiring about 0.1% of the database (see 
figure 2-5) one lock per entity produced the greatest 
machine utilization under the worst case and random place¬ 
ment assumptions. However, even with small tr an sac ti or. s , 
the degree of improvement was small as the granularity 
increased beyond a certain limit. For example, 90% of the 
maximum machine utilization was reached with 200 locks. 

Next, the simulation was run with mixed size transac¬ 
tions (AMEAN = 250, 3MEAN = 5, ALPH = .1) using the best 
case, the worst case and random access assumptions. 
Intuitively, this simulates a few large transactions and 
many small ones. As previously stated, under the well- 
placed assumption a small number of granules is best. A 
relatively flat curve relating machine utilization and the 
number of locks is observed for the worst case and random 
access assumptions. Thus, in these two cases, the granu¬ 
larity of locks, whether coarse or fine, did rot greatly 
effect the useful machine utilization. In fact, 9B% of 
the maximum utilization was achieved with both 10 and 2500 
granules. The basic problem with fine granularity was 
that the expense of rurring just a few large transactions 
seemed to outweigh the gain due to the increased cor- 
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currency experienced by the small transactions. 

3.2.2. Size 

Under a uniform distribution of transaction sizes, 
the number of entities required by a transaction was 
determined by the RAD parameter. The simulation was run 
under the well-placed lock assumptions with RAD values of 
1, 25, 50, 100, 250 and 500 or a data base containing 5000 
granules. The first case results in an initial average 
transaction size of 1/1000 th (1*NTRAN/2)of the database. 
The last case on the other hand, results in an average 
transaction size requiring one half (500*NTRAN/2) of the 
entities in the database. 

As the needs of the transactions increased, maximum 
machine utilization and throughput were obtained with 
fewer and fewer granules. Minimum response time behaved 
similarly. The optimum 1* and 5% intervals of useful I/O 
are presented in figure 2-6. Note that even for very 
small transactions, 95" of the optimum was reached with as 
few as 10 granules. 

The two other d i s t r i hut i or 1 s of the transaction sizes 
were also tested in order to model different transaction 
environments. With an exponential distribution, with the 
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same mean value as the uniform distribution 
(AMEAN=RAD*NTRAN/2 ), the results were very similar. For 
a small AMEAN, say 5 entities, 500 granules were optimal. 
Again, however, 10 granules produced useful machine utili¬ 
zation within 5% of the utilization realized with the 500 
granules. With an exponential distribution and an AMEAN 
value of 250 entities, on the other hand, 40 granules was 
again optimal. In that case, the larger transactions 
realized too much locking overhead with the less coarse 
granularity. 

However, with a hyper-exponer.tial distribution, the 
"large" transacticrs (those determined by the BMEAN param¬ 
eter) dominated the processing. Thus coarse granularity 
was again favored. For example, with AMEAM, BMEAN, and 
ALPH values of 5, 250 and 0.1 respectively, an NGRAN of 50 
still produced the maximum useful computer utilization. 
In this case, the average transactior size was about 30 
entities. But 10 percent of the transactions accessed on 
the average 250 entities and these transactions dictated 
coarse granularity. 

The simulation was also run under the random lock 
placement assumptions varying the granularity ard transac¬ 
tion sizes. For these experiments, the IORATE and CPURATE 
were again equal and the LIORATE was set to zero. The 
other parameters were identical to those described in the 
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initial scenario. With an average transaction size of 
less than 25 entities, the finest granularity was agair 
optimal. When the average transaction size was between 25 
and 50 entities, the useful computer utilizations at 1 and 
5000 granules were approximately equal. With an average 
transaction, size greater than 50 entities (1% of the data¬ 
base), ore granule was ontimal. 

3.2.3. D ataba se Si ze 

Simulation experiments were also run with various 
granularities or a database of 50000 entities. The aver¬ 
age transaction size was fixed at 250 entities and the 
simulation was rur. for 15000 time units. The effects of 
increasing the database size was similar to the effects of 
decreasing the transaction size. With well-placed locks, 
the optimal granularity occurred at 500 granules. In this 
case, five percent of the maximum utilization was realized 
with 20 to 2500 granules. With random lock placement, the 
finest granularity was again optimal. 

3.2 J) . Idle Time 

For some applicatiors, locks car be held while a user 
or aDolicatior program pauses for some duration (often 
thought of as "head scratching"). The simulation was 
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modified to reflect this effect by holding all locks for 
an idle period of 100 time units (say, for examole, about 
25 seconds in the interpretaticr mentioned at the begin¬ 
ning of this section). The simulation was then run with 
the parameter settings of the initial scenarios shown in 
Tables 2-5 and 2-6. 

The results were remarkably similar to those ir. Table 

2- 2. The useful I/O curve had slightly more variation 
than the curve in figure 2-2 with a peak occuring at 50 
granules. Ten granules still produced useful I/O and CPU 
times within 55? of the optimum. Hence a small number of 
granules was still best even with substantial pauses in 
the transaction processing. 

3- 2.5. Workload Parameter Summary 

The lock placement assumptions clearly had the most 
dramatic impact or: the machine utilization as a function 
of locking granularity. The second most important parame¬ 
ter was the size of the transactions accessing the data¬ 
base . 


Fine granularity may be best if the following two 
conditions were meet: 1) almost all of the transactions 
are small and 2) access patterns are random with no 
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sequentiality. Under these conditions, the grenter the 
number of locks. the greater the machine utilization.. 
However, the rate of increase dropped dramatically after a 
certain level of granularity was obtained (about 200 
granules in our simulation). Hence "medium" granularity 
did almost as well as fine granularity; coarse granularity 
was unacceptable in these cases. 

If too many of the transactions access a large por¬ 
tion of the database, fine granularity produces too much 
locking overhead and coarse granularity was again to be 
preferred. 

Regardless of the transaction sizes, if the data 
access patterns were primarily sequential, coarse granu¬ 
larity was still the most effective. 

3-3. Effects of the System Parameters 

The locking granularity, determined by NGRAN, has 
been the major system parameter studied so far. This 
parameter is clearly the ore over which the system imple¬ 
mentors have the most control. The effects of the other 
system parameters or the system throughput and utilizatior 
are presented below. In particular, the IQRATE and I00VLP 
parameters were varied in order to "balance" the 1/0 and 
CPU requirements of the transactions. Also, the LTORATE 
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and LCPURATE oarameters were varied to control the locking 
overhead. In additior, for each parameter, its ir.terac- 

A 

tior: with the locking granularity is also discussed. 

3.3*1. I/O \^er sus CPI 1 Ba 1 ance 

The effects of the ratio of the required I/O time to 
the required CPU time per entity was investigated. The 
CPU rate (CPIJRATE) per entity for a transaction was held 
fixed at .05 units/entity. The simulation was run with 
I/O rates (IORATE) per entity set at .01, .05, .1, .2, and 

.3. For each setting of the I/O rate, the number of 
granules (NGRAN) was varied from 1 to 5000. The lock I/O 
rate per granule was set equal to the I/O rate per entity 
in order to reflect the locks being on the same speed dev¬ 
ice as the data. F.ach simulation ran for 5000 time units. 
The cither input parameters had the values indicated in 
Tables 2-5 and 2-6. 

Under the well-placed lock assumption, the useful I/O 
curves for each setting of IORATE were bell shaped and 
heavily skewed towards a small number of granules. As 
such they were similar to the curves in figure 2-2 ard are 
not repeated hf’re. The peak of these curves occ urred with 
somewhat finer granularity as the IORATE came closer to 
the CPURATE. With a system balanced betweer I/O arid CPU 
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requirements the maximum utilization of both CPU and I/O 
resources was possible. However, even with balanced tran¬ 
sactions, 100 granules were sufficient to achieve the max¬ 
imum machine utilization. With CPU bound transactions 
(CPURATE >I0RATF.) within 5% of the peaks was reached with 
as few as 10 granules. Varying the IORATF had little 
effect on the throughput measurements (average response 
time, and number of transactions completed) as a function 
of the number of granules allowed. The useful CPU time, 
as a function of granule size, showed a similar distribu¬ 
tion as the useful I/O. The costs associated with locking 
were again minimized with 100 granules. 

Under the random and worst case placement assumptions 
and small transactions, the finest granularity was optimal 
regardless of the I/O to CPU balance. 

3-3.2. Multiple I/O Paths 

One method of "balancing" a system that is I/O bound 
is to increase the number of I/O channels to main memory. 
In the previous runs, the I00VLP value was ore. These 
experiments thus simulated a system with ore I/O path 
between main memory and secondary storage. In the next 
series of runs, this parameter was set to three and six to 
simulate, for example, a database environment with three 
and six disk drives respectively. Other input parameters 
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were the same as in Tables 2-5 and 2-6. 


Except for greatly increased magnitude, the output 
parameters had a similar distribution as those in Table 
2-7. The useful I/O time (IJSEFULIO) versus the granular¬ 
ity, for simulation. runs under the well-placed lock 
assumptions, are shown in figure 2-7. Note, with 10 to 
100 granules, the useful T/0 increased by a factor of 
about 2.5 for three I/O paths as compared to the useful 
I/O with one I/O path. (The best results possible would 
be increased useful I/O by a factor of 3.) Moreover, as 
the number of granules increased three drives became less 
and less effective. For 2500 granules, for example, only 
a 1.5 factor increase in useful I/O was realized. The 
results for six I/O paths were similar. Ten to one hundred 
granules tripled the increase in useful 1/0. With 2500 
granules, the increase in useful I/O was slightly less 
than, doubled . 

In the random and worst case lock placement experi¬ 
ments, the finest granularity was again, favored as addi¬ 
tional parallelism was made possible. 

3.3.3. Lock 1/0 Costs 

In the previous experiments, the lock 1/0 rate 
(LI0RATE) was equal to the transaction I/O rate (IORATF.). 




Useful I/O lime 
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In the next series of simulation runs, only the lock I/O 
rate and the granularity were varied. The simulation was 
run with other parameters as in Tables 2-5 and 2-6. The 
useful I/O times (USEFULIO) for the well-placed lock 
assumptions are shown in figure 2-8. 

As the lock I/O rate decreased, a larger number of 
granules could be afforded before the advantages of more 
parallelism were outweighed by the locking overhead. Of 
particular interest is the situation where the LIORATE was 
zero. This case is analogous to keeping all locks in 
main memory. Even with no lock I/O costs, there was a 
very flat extremum for USEFULIO between 10 and 200 
granules. Having a granule correspond to fewer than 25 
database entities (number of granules > 200) resulted in 
noticeably poorer performance. If the interpretation of 
an entity is a 612 byte page (or a 4096 byte sector) a 
database management system should thus not 'protect' less 
than 13,000 (or 100,000) bytes of data with one lock. 

3.3•4 . Lock CPU Costs 

The CPU costs for setting one lock were dependent or 
the lock management algorithms. To investigate the 
effects of varyirg the CPU rate for locking or the desired 
granularity, the simulation was run with CPU lock 











(LCPURATE) corts per lock of .005, .01, .025, .05 . .075, 


and .1. For this series of experiments, the LI0RATE was 
set to zero to simulate the effects of maintaining all 
locks in main memory. Other parameters were as in Tables 
2-5 and 2-6. 

Under the well-placed lock assumption and a small 
number of granules, the CPU lock costs (L0CKCPU) were 
approximately linearly proportional to the CPU rate per 
lock (LCPURATE). In these cases, there were enough unused 
CPU resources available for locking. For a large number 
of granules, however, the CPU lock costs increased 
slightly less than linearly with LCPURATE. In these 
cases, the locking CPU utilization interfered with normal 
transaction, processing. For all CPU lock costs tested, 
however, the minimum locking costs occurred at 10 
gran ules. 

Under the well-placed lock assumption the maximum 
amount of useful CP'l and I/O occurred with 10 to 100 
granules and was about the same regardless of the lock CPU 
rate. With lock CPU rates of less than 1 millisecond 
(LCPURATE = .005), the peak occurred at 100 grarules; 
within 1% of that peak occurred with 10 to 1000 grarules. 
With lock CPU rates between 1 and 5 millisecords (LC p URATE 
= .005 to .03) the peak was at 50; but the useful 1/0 and 
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CP'J dropped off sharply with more than 200 granules. With 
higher lock CPI) rates, 10 granules were optimal and at 
most 100 granules for the locking granularity were afford¬ 
able. 

Simulation experiments were also run varying the lock 
CPU costs under the random lock placement assumption. In 
these experiments all transactions were small (AMEAN = 5, 
ALPH = 0) and the LIORATE was again set to zero. The CPU 
and I/O rates for transaction processing were both about 
30 mil 1iseconds per entity (IORATE = CPURATE = .2). In 
these experiments, an increase in lock CPU rates greatly 
affected the computer utilization at the finest granulari¬ 
ties. With a 5 millisecond lock cost (LCPURATE = .03), 
the useful computer utilization was 5% of the utilization 
observed with a 2.5 millisecond lock overhead cost 
(LCPURATE = .015). However, the finest granularity was 
still optimal until a 15 millisecond per lock overhead 
cost (LCPURATE = .1) was incurred. 

3-3.5. S ystem Para meter Nummary 

Some of the system parameters did suggest somewhat 
finer granularity under the well-placed lock assumDtiors. 
In particular, two factors had some effect on the optimum 
granularity. When the resources expended for locking were 





68 


reduced, finer granularity was affordable. With lock I/O 
costs of zero and the lowest setting of lock CPU costs, 
100 locks was optimal. Even in these cases, though, too 
fine a lock granularity was not acceptable. 

The second factor which had an. effect on the optimum 
granularity was the balance between the CPU and I/O 
resource needs of the transactions. Under a balanced sys¬ 
tem load and the well-placed lock assumption 50 to 100 
locks were again optimal. 

Under the random and worst case lock placement 
assumptions, in most cases, the lock cost parameters 
(LCPURATE, LI0R4TE) did rot change the optimal granular¬ 
ity. The other system parameters had no affect or. the 
optimum granularity under these placement assumptions. 

3.^. System Extensions 

In the previous experiments all granules were assumed 
to be the same size and all of the locks were acquired at 
the beginning of a transaction. In this section two 
mod i f icat i or: s to the model are introduced to study alter¬ 
nate assumptions. In the first extension a lock hierarchy 
is simulated. In a lock hierarchy, transactions of d l f- 
ferent sizes lock different sized granules. In. the secord 
extension, a "claim as needed" locking strategy is simu- 
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lated. I r. that strategy, tr an sac ti or: s acquire locks as 
they need the corresponding entities. 

3.^.1- Lock Hierarchy 

In many of the previous experiments it is noted that 
the expense of locking a large number of granules by a 
large transaction offsets any increase in parallelism 
realized by fine granularity. One way a large transaction 
can avoid the expense of locking many small granules might 
be to have the large transactions lock large granules 
while the small transactions continue to use the small 
locks [GRAY76], 

3 .^. 1 . 1_. Thj? Model. Ex_tersix)n 

In the simulation extension a two level hierarchy was 
implemented. A transaction, depending or its size, either 
requested a set of small locks or ore global lock which 
covered the entire database. 

With this extension, we explored the in teractiors 
between any two levels of a more general hierarchy. A 
more general hierarchy could be ary tree-like graph struc¬ 
ture. A transaction, could lock the root of a subtree and 
thus control access to the parts of the database covered 
by any locks in that subtree. Alternately, the 
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t r at: sac t i or s could mark the root of the subtree to indi¬ 
cate that locking is taking place at a lower level. The 
transaction would then treat each offspring of the root as 
its own subtree. 

In the extended model , the choice between, the global 
locks and the small locks simulates the choice between the 
root of ore subtree and its direct descerdents. The per¬ 
formance tradeoffs between increased parallelism and 
increased locking overhead of a more general hierarchy 
occur similarly at each node. Thus, the results of this 
extension can be applied to the more general hierarchy and 
a more complex tree structure need not be simulated. 

The simulation was modified by adding 'pending' and 
'blocked' queues for the global lock. If a transaction 
was "small", it set the global lock in shared mode and was 
placed or: the original pending queue. From that queue the 
"small" transactions competed for the small locks as in 
the original model. If the transaction was "large", the 
global lock was set for exclusive access and the transac¬ 
tion waits for all active transactions to finish. With 
the global lock set for exclusive use, new transactions, 
regardless of size would also wait in the blocked queu n . 
Once the large transaction was allowed to proceed, it went 
directly to the I/O queue bypassing the s nail lock cor- 


trol . 
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The simulation was used to study the effects of 
tain parameters of such a hierarchy or the desired grar.u- 
larity. One of the main areas of lr.terest was the cri¬ 
teria for dec id ir: g whether the small locks or the global 
lock should be used. An input parameter was added to the 
simulatior: which specified the threshold percentage, TP, 

of the database which must be touched by a transaction 
before it was declared "large". If a transaction used 
less than TP percent of the database, the small locks 
would be used. Otherwise, orly the global lock would be 
set. 

3.4.1.2. The Si mul ation R es ults 

The simulation was run with threshold percentages of 
0.1%, 0.2%, 0.5%, 1%, 2%, 5%, 25%, 50% and 100% for each 

of a large number of other parameter settings in order to 
find the value of TP which maximized useful machine utili¬ 
zation. The optimum threshold observed was dependent on 
the number of small locks, the assumptions concerning the 
placement of those locks, the number of entities touched 
by the tran sactiors , and the size of the database. 

figure 2-9 shows the effects of the threshold percer- 
or machine utilizatior in two instances with dif- 
-tj-'-crs of small locks. For both of those cases 


- -. •«1 transactions were used and well-placed locks 
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Figure 2-9: Computer Utilization versus 
Threshold Percentage in a 
Lock Hierarchy. 
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were assumed. With ter smal l looks , the m.ix huti ma<. hir e 
utilizatior was reached with thresholds of BO ard 100 per¬ 
cent. A threshold of 100® resulted ir: all trar: r.ncti or s 
usinr, the small locks, i.e. as if no hierarchy were 
present. However, with 1000 small locks, for example, a 
threshold of 5 percent was optimal. Charging the assump¬ 
tion about the placement of the locks also made a dramatic 
difference. 

Figures 2-10 and 2-11 further explore the effects of 
the number of small locks or: the threshold oercertages. 
The results ir Figure 2-10 reflect the "well-placed" 
assumption. Random access to the database was assumed for 
the simulation results shown in figure 2-11. 

Each of the graphs is divided into three areas based 
on machine utilizatior . The "optimum" line represents the 
threshold value, TP, at which the maximum I/O and CPU 
utilization was observed for a giver number of small 
locks. With threshold values in area 5, the hierarchical 
locking produced results within ?% of that maximum utili¬ 
zatior-. In area A, the utilizatior was less than in area 
B. I p - this case, too few transactions used the global 
lock, i.e. the threshold, TP, was too high. Ir. area C, 
the machine utilizatior was also less than in area B. In 
this case, however, too many transactions used the global 
lock, i.e. the threshold, TP, was too low. 




For example, consider figure 2-10 with 1000 small 
locks. The machine utilization increased as the threshold 
percentage was increased from 0.1 % to 5%, but decreased as 
the threshold increased from 5% to 100%. However, simula¬ 
tion runs with threshold percentages between 1% and 25% 
produced within 2% of the machine utilization observed 
with the optimum threshold. 

In figure 2-10, "we 11-placed" granules were assumed. 
With more than 1000 small locks the optimum value of TP 
was between 1% and 5%. With the number of locks between 
10 and 100, TP values of 50% to 100% were optimal. In 
this granularity interval, the 2% area included the case 
where all transactions used only the small locks. The 
overall maximum machine utilization occurred in figure 2- 
10 with 10 locks and TP values greater than 50%. In these 
cases, almost all of the transactions used the small 
locks. Hence, the value of a lock hierarchy under the 
well-placed locks assumption was very small. 

However, in figure 2-11, random lock placement was 
assumed. With coarse granularity, the optimum threshold 
occured at 0.5%. With a higher threshold, mere of the 
smaller transactions would use the small locks, and conse¬ 
quently would lock a large portior of the database. As a 
result, these transactiors would exDend more resources for 
lockirg than if the global lock were used without sigrifi- 
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cantly increasing the concurrency allowed. 

In figure 2-11, the differences in computer utiliza¬ 
tion between areas A, B, and C was small for coarse granu¬ 
larity. For 10 granules, for example, no matter what 
value of TP was used, the computer utilization was within 
3% of the maximum observed for that granularity. Simi¬ 
larly, for 100 granules, the computer utilization was 
within 15% of the maximum observed for any value of TP. 
Thus even with random lock placement, a hierarchy with a 
small number of small locks, at best, provided slight 
improvement over a single level locking system. 

Under the random access assumptions, the overall max¬ 
imum machine utilization occurred with 5000 granules arid a 
TP of 1%. The cross-hatched area in figure 2-11 
represents those combinations of TP and number of small 
locks which resulted in machine utilization within 2% of 
the overall maximum. Hence, fine granularity was pre¬ 
ferred. The lock hierarchy effectively prevented exces¬ 
sive locking overhead for large trapsactiors . The coarse 
granularity, or the other hand, resulted in Doorcr useful 
machine utilization regardless of the TP setting. With 11 
granules, for example, the USFFULIO was orly 3/1 of the 
maximum USFFULT0 observed with 5000 granules are a T (J of 
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For fine granularity, the B areas in figures 2-10 and 
2-11 had considerable overlap. For example, in figure 2- 
10, with 2500 small locks, the 2% of optimum interval 
occured with a TP between 0.5% and 10%. In figure 2-11, 
with the same number of small locks, the interval occurred 
with TP values between 0.5% and 5%. Thus, at this granu¬ 
larity, a TP between 0.5% and 5% could safely be chosen, 
regardless of the randomness of the data access patterns. 

In other simulation runs, as the average transaction 
size decreased, the range of acceptable TP values (area 0) 
also decreased. With fine granularity, regardless of the 
transaction sizes, a threshold between 1% and 2% always 
produced machine utilization within 2% of the maximum. 

With coarse granularity, however, changes in the size 
of the transactions, created non-over lapped intervals of 
acceptable TP values. In other words, no one value of TP 
could be chosen that would be correct for vastly different 
sized transactions. Thus much greater care must be 
applied to a hierarchy with coarse granularity. Further¬ 
more, a stable transactior size envirormert must be 
assumed. 

The size of the database was also varied. For exam¬ 
ple, the simulatior was run with a database cersistirg of 
only 16 entities. In this scenario, the Dossibie irterac- 
tior: of a page/rocord hierarchy was examined. Ar entity 





79 


corresponded to one of 16 records in a page. The simula¬ 
tion was then used to model the effects of locking the 
whole par,e by the global lock, or locking individual 
records by the small locks. Some increase in machine 
utilization, was observed with a threshold of 50%; but the 
increase over using no hierarchy at all was less than 4%. 
Again it appeared that a lock hierarchy covering orly a 
small number of smaller locks was not worth implementing. 

The simulation was also run with databases of up to 
100,000 entities. The results were similar to the results 
produced with a database of 5,000 entities. For example, 
experiments were run where the average transaction size of 
most of the transactions was just 0.05% of a 100,000 
entity database and the average size of a few large tran¬ 
sactions is 1% of the database. In these cases, with the 
finest granularity (100,000 small locks), a threshold of 
1% was still optimal . 

Other simulation experiments used the worst case data 
access assumption and produced results very similar to 
those in figure 2-11. 

3.4.2. Cl aim As Ne_eded Locking 

There is another difference between the original 
model and some database concurrency cortrol implements- 








80 


tiors. In the original model, a "preclaim" strategy was 
assumed where all of the locks were acquired before any 
transaction processing took place. In some database sys¬ 
tems, a lock is not acquired until the related entities 
were actually needed by a transaction. These "claim as 
needed" schemes are used either to reduce the total time 
locks are held and/or because the locks to be acquired 
depend on data values of entities already accessed. In 
these cases, some locks may have to be held while other 
locks were requested, and deadlock can occur [C0FF71]. In 
this section the effects of a claim as needed scheme are 
examined. 

3.4.2.2- Ttie M odel E xtension 

The simulation was modified by cycling each transac¬ 
tion through the I/O and CPU queues (see figure 2-1) or.ce 
for each lock required. The total I/O and CPU times 
required for a transaction were the same as in the origi¬ 
nal model and were equally distributed among each of a 
transaction's cycles. 

Between, each cycle, a transactior requested ore lock. 
If the lock was granted, the transaction went or the 
active queues. When a transactior completed its last 
cycle or the active queues, all its locks were released as 
in the original model. 




If the lock was denied, the requesting transactior 
was placed on. the blocked queue. The lock could be denied 
due to locks held by either' another active transaction, or 
by a blocked transaction. In the latter case, the block¬ 
ing transaction was on the blocked queue, and a deadlock 
condition could exist. If deadlock occurred, a victim was 
picked for backout. The locks held by the victim were 
released, any blocked transactions were freed, and any 
time spent on the active queues by the victim was added to 
a "lost time" total. 

3.4.2.2. The Simulation Results 

The modified simulation was run varying the sizes of 
the transactions, changing the lock placement assumptions, 
and with and without a lock hierarchy. Again it was 
assumed that there was no I/O cost associated with locking 
and that the transactions required equal amounts of CPU 
and I/O resources. 

The results of these simulation runs were very simi¬ 
lar to the results from the preclaim strategy. In all 
cases, a claim as needed strategy did not change the 
granularity required for maximum machine utilization. 

For example, figure 2-12, shows the results of run¬ 
ning the simulation with no hierarchy, well placed 
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g r ar u 1 '• s nr d ' • .*r r.noti .nr si;'o r. < >;• ? «r";ir oi by a r.vD**”- 
gx por or t i •*, 1 d i rt hut j -» . The lest, time area i r «. 1 ud ed the 
mac hi r utilizer i : bv t r .j: bier s that. had be. tie res¬ 

tarted due bo d e *i 11 c-i- k . The useful c o m r J t i r g i r c 1 u d ed 
or 1y the CPU resources used by successfully completed 
trar sactior.s. 


It: the simulatior exoor imer t s, the locking cost 
observed i r; the nr eel aim model was greater thar. the lock¬ 
ing cost observed ir the claim as reeded locking model . 
Ir. the or eel aim model, ir the case of a lo-ck request 
failure, all of th° locks hoi to be requested acair . Ir 
the claim as r eede^ model, ir th» cose of a lock request 


failure or.ly the der ied lock had to be rerequested. 


how¬ 


ever , ary decrease ir' lock costs ir the claim as reeded 
model was more thar offset by the lost time due to res¬ 
tar tir.fr tr ar. sac t i or. s . Thus, the useful mac hi r. e utiliza- 
tior was greater ur.der the preclaim model thar under the 
claim as reeded strategy. Mary other cases with different 
tr ar sac t i or. sizes ard lock placemert assumption s were also 
tested ard produced similar results. 

For ex amol e , figure ,—11 cnr'i’"' 1 ' bh ^ use f 1 r 1 m a *. r i * e 


util i7 a tier b o b w ° e r b ho b wo models u - ~., p \ r, r s s u ~ - b i o- r 
that all tr ar sa^ t r ' r r. «■«'•# small ar d that e,n» h t r ar s a >. tier 
had random data access mtterrs. Ir both of these ruts, 
the average trar sac*ior riz Q was C.1% of the database. 
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"Proclaim" versus "Clair: ' Needed" 
with Random Placement of Lock.-. 


Figure 2-13 




AD-A103 141 
UNCLASSIFIED 


CALIFORNIA UNIV BERKELEY ELECTRONICS RESEARCH LAB F/G 9/2 

THE EFFECTS OF CONCURRENCY CONTROL ON DATABASE MANAGEMENT SYSTE—ETC<U> 
APR 70 D R RIES N00039-78-C-0013 

UCB/ERL-M79/20 NL 



























Note t. hat, w i t h t '■V ' 1 p o s 3 i b i 111 v : d e a :! •: , ?f. ;u ■:.* '• 

ut i 1izatior curv ft iii r -,? f 1 at v •: out as th" ’,rn: ul :r:tv 
i rcroar.? i . Thus , the forest. r*rar ul ar i t v i r. : . : r htly more 
ber ef it ial with the claim as r ee^oi m;• del than with a pre¬ 
claim model. hole, however. that the claim as reeded 
scheme again. produced less useful 1/0 arid CPl T utilizatior 
than the proclaim model. 

However, as the average transaction size became ever: 
smaller, the last observatior did rot hold. With ar: aver¬ 
age transaction size of less than 0.05' of the database, 
random data access patterns, and the finest., granularity, 
the claim as needed scheme resulted in greater useful 
machine utilization. Under these conditions, the claim as 
needed strategy allowed the greatest concurrency since 
locks were held for a shorter Deriod of time. In. contrast 
to other runs, very few' transactions had to be backed out 
and the cost of rerunning such small transactions was 
in significant. 

The modified simulatior was also rur with a lock 
hierarchy ar.d various threshold percentage values. A 
similarity in the shapes of the curves betweer the pre¬ 
claim and claim as reeded st ’’a te ie s was also observed. 
Under the random access assumotl:rs , for example, the max¬ 
imum machine utilization was again reached with the finest 
granularity ard a threshold value of 1 to ? percent. 
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< , , g . S U TT 'I! V 

A locking hierarihv should be implemented when the 
small locks are of a fir.e gr an ul or i t v; a low threshold was 
used to separate the lnr^p ar:d sTall trap sac tier s; and 
rardo'n data access uattorrs were anticipated. Under these 
assumptions the ir.crease in machine utilization over a 
single level 1 oc k 1 n g scheme was significant. Furthermore, 
a threshold of about one percent produced the best results 
ir.deperdert of the granule placement or transaction size 
assumptions. 

With coarse granularity, or: the other hand, a lockin'!’ 
hierarchy was not beneficial. The benefits of such a 
hierarchy were not significant and were only realized ir: 
certain. cases. Another problem with the coarse 
gr ar. ul ar i t y/loc ki ng hierarchy model was that the optimum 
value for the threshold percentage was extremely sensitive 
to the placement of the locks with respect to the transac¬ 
tions. 


The acquisition, of locks throughout the processing of 
a transaction did ret significantly charge th« other cot - 
elusions. However, several observation s were made. 
Deadlock detection ar d resolution ar.n>« ared to be generally 
more expensive than the release and reroquert used in the 
preclaim strategy. Thus, when locks were kr.cwr. at the 







Start of a tm- sacti or , ore,! al gc r i ‘ 


s 


n. cnv-'i.'ir; 


The activity and rffoits of a locking 'Vi.hr i r.m were 
simulated to study the tradeoffs between increased paral¬ 
lelism of concurrently runnier, tr an sac tier s and increased 
overhead caused by sophisticated and complex lockirr 
meohar isms. The conclusions of the study are first 
applied to physical granules. The application of these 
results to predicate lockir g is then discussed. 

K Physical Lockirg 

Under the assumptions mentioned in the description of 
the model, in many cases a small number of granules is 
sufficient to allow enough parallelism for efficient 
machine utilization. Furthermore, a large number of 
granules, corresponding to locking a page or record is 
ofter. extremely costly. 

These basic corclusiors are due to the fed ’ c wir ~ 
observations. For large transactions, fire grar u; i tv 
becomes too expensive. A transaction which accesses half 
of the database, for example, would spend ctrsiderabie 
resources locking each page. Yet. little pair in parallel¬ 


ism would he realized since other transactions would have 





a strct g r>i-rh i ] i t v c f iorf1ut:rg wi 1 r. th rt large trar - 
sac-tier . A small trar sac t.i • ? wh i >. h ac». esses or 1 v ore 
page, or th n other hard, must lc^k s ’nuvli larger grar.ul e. 
The result art loss in parallelism is nir: ini zed because the 
small trarsaetior would or.lv hold the lock for a short 
period of time. The probability of conflict and the 
length of any waiting period would rot be large due to 
that short period of time that the lock is held. 

However, there are corditiors where these observa¬ 
tions do not hold. Details of which eorditior.s support 
which level of granularity are presented below. 

If equal sized lockable granules are assumed, a small 
number of granules (10 to 100) are sufficient under any of 
the following corditiors: 

1) The locks are well placed with respect to the running 
trar: sac tier s . 

?) The number of entities required by trarsactiors vary 
in size and include at least some trarsnetiers that 
require access to a large number cf er titles. 

3) Some per tic? of the l.ckirg sc h^me i r velvet, extra I/m 






Howov^r , c.-'k h .f the fo-l 1 ~ fut tr- : j»- r. ..rtr some- 

what finer gran ul nr i tv : 

1) All of the trnr riictior s ire extreme! v small ar d 
access less than 1% of the database. 

?.) The length of time that locks are held is extremely 
lor.g and rot Droportioral to the size of the transac¬ 
tor , as was the case with the "idle time" experi- 
men ts . 

31 The locking costs are reduced, for example, by keen- 
in g all locks in core. 

4) A balance exists between the I/O resources and CPU 
resources required for processing a trap, sac tier . 

If all of the following conditions are met, the 

finest granularity should be used: 

1) All of the transactions are small. 

2) The locking costs are reduced by, for example, keep¬ 
ing all locks ir. core. 

31 Random access patterrs (or worse) are exhibited by 


the tr ar. sac tier s . 




However, if ccrditicr 1 is v jointed, a 1 <,<. k hierarchy 
must he used if the fine granularity is still to be sun- 
ported . 

The overall coiclusior is thus that the optimum lock¬ 
ing granularity is somewhat applicatior dependent. In 
many cases, coarse granularity, such as file or relation 
locking, with a proclaim strategy is to be preferred. In. 
other cases, somewhat finer granularity, such as area or 
extent locking is best. In. still other cases, the finest 
granularity such as page or record locking is required. 

4.2. Predicate Locking 

Four results from the simulation support the poten¬ 
tial viability of predicate locking. Firstly, with predi¬ 
cate locking only a small number of locks must be main¬ 
tained and can. probably be maintained in main memory. The 
number of locks is proportional to the number of active 
trar.sac.tiors and rot to the size of the database. 

Secotdly, while predicate locking may require more 
CPU time per granule thar Physical locking, the simulation 
results irdicate that, for coarse gran, ul ar i t v, some 
increases in locking overhead are affordable an d do rot 
significantly ir ter fere with trnr sac * io r processing. 




Thirdly, the- parameter \ >. p had c or si d^r nb) e f fe«.. t 
or the dosirr i r inbor of ".rat ul or ms the rubber of enti¬ 
ties ' toiK h--d ' by the t r or r."u t ; r * s. As the trar sactior 
size decreased, the desired rubber of granules ir creased. 
Note, ir predicate locking sc hones, the portior of the 
database locked is determined hy the trar: sactior , and rot 
a presoec i f ied qranul ar i tv , effectively mimickir r the 
above variable nr ar. ul ar i ty . 

Fir ally, the results of the lock hierarchy simulatior 
m i q h t indicate that a simple predicate locking scheme 
mip.ht be sufficier.t. It: ore such scheme, two types of 
locks could bp sun nor ted. First an er. tire r el at i or , 
record tyoe or file could be locked. The small locks 
would be based or a simple unique key-value pair. The 
predicate lockirq scheme could easily check whether a 
key-value pair corflicted with either ar. entire relation 
lock or other key-value pairs. The lock hierarchy simula¬ 
tion results indicate that orlv a small rumber of key - 
value nairs would have tc be mairtair.ed before the 1arqer 
style lock should be aunlied. Furthermore, the simulatior 
results indicated that subsettir •- the trar sac tier? tv less 
dense attributes (ores with crly a hardful of differert 
values) would rot be bereficial ir a lock hierarchy. 
Thus, in these cases, keeoirq the predicate locking 
mechanism quite simnle would be justified. 
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However . such ■< si-v.-l e urn-lie * In 1 ci' g mec hnr : om is 
rot very d 1 f f er«r. t fVo: 3 simple :hvsif".1 lock h i er arc h v . 
For example. locking ; 1 ■: gi«. r«l i elatior '^iv ir some imple¬ 

mentations be identical to 1 ockire a physical file or 
area. At the finest grnr ul ~.r i tv, a predicate lock of a 
unique key-value pair identifies ore record. A physical 
lock, or the other hard, would uniquely identify the same 
record by a physical address. Thus, in terms of parallel¬ 
ism and operation, a simplified predicate locking scheme 
is identical to a physical locking scheme. The physical 
locking scheme, however, may be easier to implement. 
Moreover, the physical address for a record might take up 
less space in a lock table than a predicate lock for the 
same record. 

Another problem exists with predicate locking. Ir. 
some applications, a seccrdarv key or index is used to 
access a given record type. L'rder the simple predicate 
locking hierarchy described above either all access via a 
primary key would have to wait for the seccrdarv index 
applicatior to complete; cr the recc'd would have to be 
read, the key value obtaired, nrd th°r a lock requested. 
Wher the lock is grnr ted tr.° record w wld have to be 
reread. With physical leks. cr the ether hard, the phy¬ 
sical record address woul 1 to ur ique . 








f; 


Ir summary, th'-r , whi 1 <• pred is- ate 3 •: k i r •* m a y k 
viable, it rices riot seem to ho worth the extra imtlemer t ? 
tier: and locking overhead, because it car c-rly be aonl ie 
wher specific sets of the database r.eod to be lcckir.r 
Furthermore, those cases car. be handled adequately b 
similar physical locking schemes. 




CHAPTER 3 


DISTRIBUTED DATABASE SYSTEMS 

1 • in troducti on 

In the previous chapter, simulation models were used 
to investigate the performance issues of concurrency con¬ 
trol in a centralized database. In this chapter, those 
simulation models are extended to study the performance 
issues of concurrency control in a distributed database. 

1 * 1 ' D istr ibuted Da taba ses 

In a distributed database, the data is stored at mul¬ 
tiple computer sites connected by some tyoe of computer 
network. In. this environment, a transaction originates at 
one of the computer sites and potentially accesses data at 
other (or remote) sites as well as at the originating 
site. 

The benefits of a distributed database include the 
ability to share and access eecgr a nh i c. a 11 v distant data, 
to exercise some local ccrtrcl ever subsets of the data¬ 
base, to provide mc d u1 ar growth ard re si1iercv to the 
database, ard to increase the ootertial parallel is.m 
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allowed in accessing the database. 


9 b 


1.2. Pistr ihu ted Database Concurrency Control 

The distributed concurrency cortrol mechanism must 
guarantee the same type of consistency which was reeded ir» 
the centralized database. However, the performance issues 
in a distributed database are different than in a central¬ 
ized database. This difference is due to the following 
f actors: 

1) More parallelism is possible because multiple sites 
can simultaneously process transactions. In the cen¬ 
tralized model, at most two servers, the I/O and CP'J 
processors, could be kept busy. In an N site system, 
there are 2*N servers which can be simultaneously 
processing transactions. 

2) The overhead associated with distributed concurrency 
control will be higher than the overhead required in 
a centralized database. The additional overhead is 
due to the costs required to set locks at remote 
sites and/or the costs which may be required to 
resolve deadlock between trarsections at different 
sites. The remote lockirg overhead is due to the 
network delays involved with sending and receiving 
lock messages. The deadlock resolutior overhead 


includes the computer resources required to detect 
deadlock and to roll back certain transactions. 

The simulation model for the centralized database 
concurrency control was extended to investigate the 
trade-offs between the increased parallelism and increased 
overheads of a distributed database. The major areas of 
study include the effects of varying the locking granular¬ 
ity, varying the percentage of transactions requiring 
non-local or remote resources and varying the throughput 
and bandwidth of the network. 

In the next section, the extensions of the simulation 
model which apply to all distributed concurrency control 
algorithms are discussed. In section 3, four different 
concurrency control algorithms and their associated simu¬ 
lation extensions are discussed. In section 4, the simu¬ 
lation results for each of the four algorithms are 
reported. In the final section, the major conclusions are 
stated . 

2. MODEL EXTENSIONS 

In this sectior the model exter sicr s are described. 
First, the network model is reviewed. Next the acticrs at 
each of the nodes or network sites is discussed. Fir ally, 
the input and output parameters of the model are dis- 
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cussed. Throughout this section, only the processing of 
transactions will be considered. In the next section, 
four concurrency cortrol algorithms will be integrated 
in to the model. 


?*!• Ne twor k Mo de l 

The network is considered to be a collection of com¬ 
puter sites called nodes, all corrected by a "logical net¬ 
work manager" as shown in figure 3-1. This manager could 
represent a specific star like network, or a more general 
node to rode network like the ARPANET [KLEI76]. In either 
case it is assumed that the time to send a message between 
any pair of nodes is the same. 

Each Node contains a message-in and a message-out 
queue. Messages are taken from the message-out queue and 
given to the Network Manager together with a destination 
and a message length. When a message has received the 
needed amount of network service, it is placed on the des¬ 
tination message-in queue. 

Both a speed and a bandwidth are associated with the 
Network Manager. The network speed is represented by the 
minimum time a message of any tvoe must soerd in the net¬ 
work where time is measured in the time units of the simu¬ 
lation. The bandwidth is represented by the maximum 




Network manager 
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NODE 0 NODE N 


Figure 3-1: Network Model 







number of messages which can be serviced in ore of those 
time units. 

The flow of a message in the Network Manager can be 
described as follows: 

1) When a message enters the network manager, the time 
remaining for that message is initialized to the mes¬ 
sage length in. the time units of the simulation. The 
message length can vary depending on whether or not 
data is being sent but is at least equal to the 
minimum length mentioned above. More details or this 
length are in section 2 . 3 . 

2) If MESSBDWH is the bandwidth of the Network Manager, 
the times remaining of the first MESSBDWH messages in. 
the Network queue are reduced by one time unit. 

3) If the time remaining for any message is zero, it is 
delivered to the message-in queue of the destination 
node. 

In several of the corcurren.cy control schemes, a site 
can send messages to itself. In these cases, ro retwork 
resources are consumed cr network delay realized, since 
the message is taken directly off of the message-cut queue 
and placed or: the messag°-ir queue. However, local mes- 
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sage costs (CPU time spent by a node handling messages) 
are included for these self-directed messages. 

2.2. Site Model 

Each site or rode in the model is very similar to the 
centralized model presented in Chapter 2. However, 
several new queues and procedures were added to process 
distributed transactions. The new model is shown, in fig¬ 
ure 3-2. Again transactions are cycled around a closed 
loop model and initially arrive ore time unit apart on the 
pending queue. 

There are three possible types of transactiors in the 
model. First, there are local transactions which are 
identical to the transactions in Chapter 2. Secondly, 
there are MASTER transactions which require access to 
parts of the database at randomly selected other rodes. 
The MASTER transactions initiate a fixed number of SLAVE 
transactions at those other rodes via messages. 

The transactiors go through the following steps: 1) leave 
the pending queue, 2) I/O orocessirg, 3) CPU nroeessirg, 
*0 data tr an sm i s s i or- , 5) local processing comeletlc: , ar d 
6 ) distributed processing syr.chrcr i ration . 

1) When a tran sactior leaves the per ding queue it is 
placed or the I/O queue. If the trarsactiot is a 
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Figure 3-2: Node or Site Model 




























MASTER, it spp.ds SLAVE create messages to the 
approoriate nodes. 

The I/O.server is multiplexed amorp the transactions 
on the I/O queue. When a transaction has received 
its share of I/O resources, it is placed on the CPU 
queue . 

The CPU server is multiplexed amorp the transactions 
in the CPU queue. When a transaction has received 
its share of CPU resources, its next action depends 
or: whether or not the transaction is local. 

Local transactions are considered complete at this 
point and recycled to the perdinp queue. Non-local 
transactions (both SLAVES and MASTERS) are placed or 
the data trar:smissior: queues. If any data is to be 
trarsmitted, a data transmission messape is sent. 
This transmission messape is in fact addressed back 
to the sendirp transaction. Thus the data trar.smis- 
sior is comnlete when this messape is delivered back 
to the oripir. atirp site. 

W her the data tr ar smi ssior messape has beer. received 
(or if re .data was to be trar smitted), the rcr- local 
trar sa*. tier or ec ends to the Network dcre queue. At 
this time, SLAVE trarsactiors send a SLAVE complete 






message back to the MASTER trar.sactior . 


6 ) Depending or: the concurrency cortrul strategy, 

SLAVE either waits on the Network dore queue or is 
simply released. The release of a slave is discussed 
in more detail in section 3. The MASTER transactior 
waits or: the Network dor-e queue until it has received 
"slave complete" messages from all its slaves. At 
that point, the trar.sactior is recycled back to the 
pending queue. 

Three tyoes of messages are common to all of the cor - 
currency control algorithms. The ac-tiors caused by these 
messages are described below. 

1) When a "SLAVE create" message is received, a transac¬ 
tion identical to the MASTER transactioi , or 1v 
flagged as a SLAVE is added to the pending queue. 

2) When a " data transmission done" message is received, 
the waiting MASTER or SLAVE trar.sactior is r c t i f i e d . 

3) When a "SLAVE complete" message is rec ev. ed, t to ' 1 
ccrrespor dir g MASTER trar.sa. t i rr s cr the twc rk i c r •-> 
queue is rotified. If the *'A TER trar ra«. tier : s ret 
completed, the message is retried t .*• t he message- i r 
queue ur.til the MASTER trar sac tier c car 1 . n * . 
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Several simplifying assumptions should be noted about 
the model. First, all of the SLAVEs are identical to the 
originating MASTER in terms of the proportion of database 
accessed and whether or not data is to be transferred. In 
distributed database applications, the actual characteris¬ 
tics of the SLAVES could be quite different from the MAS¬ 
TER and from each other. Second, the only synchronization 
between the SLAVEs and their MASTER transaction occurs at 
the beqir r iriq and end of the transaction. Some applica¬ 
tions would require additional synchronizations or: the 
data beinq transmitted [W0NG77, FPST78]. 

Also rote that a transaction is or: each of the I/O, 
CPU and data transmission, queues once in the indicated 
serial order. The total processing required is the same 
as if the transaction cyclically accessed the I/O, CPU and 
data transmission queues. 

2.R. Model Parameters 

The incut parameters <. an be divided into the parame¬ 
ters teat characterize the workload, the svstem parameters 
that characterize the irdividual r odes, ard the parameters 
that characterize the network. The workload parameters 
deter- ir e the database ard the trar.sactiors that are rur. 
aqairrt that database. As ir. Chapter 2, the system param- 
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eters determine the computer and database mar: agcner t sys¬ 
tem characteristics. The network parameters include the 
minimum time required for messages, the network bandwidth 
and the CPU and I/O resources required for processing mes¬ 
sages at each site. 

The output measurements include the overall CP'J arc 
I/O resource utilizations for transactions, messages and 
concurrency control as well as network measurements. 

These parameters, in most cases, have the same 
interpretation as in Chapter 2. All of the parameters are 
described in detail below. 

2.3.2• W orkl oad Parameters 

The workload parameters desc ribe the transact icts ard 
the portion of the database at each node. Table sum¬ 

marizes the workload parameters. 

The first five parameters are identical to the param¬ 
eters discussed in Chanter 2. For almost al 1 of t 
experiments reported in this chanter or lv 3 few s-t-, :r • 
of those parameters are used. The efforts of v ;rv'.* a 
those parameters would be similar tc the effects r«: . rt- : 
ir. Chanter 2. 

In particular, UTP't’J was set tc 10 simul ati• r 10 
transactions rurring at each node. Thr Dhfl/F. at each 
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Table 3-1 

Workload Parameters 


Parameter Description 

Local Parameters 

NTRAfl Number of transactions running at each node 

DBSIZE Size of the portion of a database at a i*iven node 
AMEAN Low-mean of exponential distribution, 
for transaction size 

BMEAN Hif»h-mear of exponential distribution 
for transaction size 

ALPH Cut point for Hyoer-expor. ential distribution 
for transaction size 
LKPLMT Lock Placement assumption 

Distributed Parameters 


PREDIST Percentage of transactions which are non-local 
PRETRAN Percentage of distributed transactions 
which transfer data 

PREDATT Percentage of data transferred by 
those distributed transactions 
NSLAVES Number of SLAVES for a distributed 
transaction. 


node was set to 10,000, resulting in a total database size 
of 10,000 times the number of nodes in the network. 

Two classes of transactions are modeled. With class 
one transactions, the transaction sizes vary considerably 
and the locks are assumed to be well-placed with respect 
to the accessir? transactions. For these transactions 
AMEAN is 5, P'lE-W is ?50 and the AL P H Dsrameter was set to 
.1. This class cf transact ions simulates a workload where 
most (90") cf the transactions are small (they access 0.^5 
percent cf the database) and a few cf the transactions are 
lar^e, 
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With class -two transaction s , all tr ar sue t i oi s arc 
small and the placement of the locks is assumed to be ran¬ 
dom with respect to the accessing tran sactior s . 

The remaining parameters deal with the non-local 
transactions and are the ones of most interest ir this 
chapter. The proportion of transactions which are MAS¬ 
TERS, the PREDIST parameter, determines the number o f 
tr an sac ti or s at each node which require processirg at som--* 
other site. Experiments were run with PEEDTST settings of 
0, 10, 25, 50, 75 and 100 percent. 

The number of SLAVES required by a MASTER are ioter- 
mined by the KSLAVES parameter. The orir.it al number of 
database entities required by the MASTER is evenly distri¬ 
buted among the SLAVES and the MASTER. Thus, if the MAS¬ 
TER originally requires E of the database en‘i1 1 o s , at 
each site where the transaction was active. 
E/(NSLAVES + 1), entities are actually accessed. 

The amour t of data to be tr.ar sferred is dotermirod by 
the PRPTRAN ar d PREDATT parameters. The P " TA b par ter 
determines the r umber of d l str ibuto i t r ar ra, *. : * •• i 
transfer ar v data at all. The PR"' ATT r ar -r i.-.t er¬ 
mines hew mary of a transaction's entities will bave *: r-? 
transferred. The number of entities tr&? sf«rre i :«t er¬ 
mines the 1 e r r t h of a data trarsfer message a n 1 h e r v e 
determines hew long a transactin'* soerds or t he tb-t w. iv 


. ..dnim 11 r f 
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wait queue. 

In summary, the database consists of a collection of 
entities at each node. Each transaction "touches" or 
accesses a certain number of those entities. Some of 
those transactiors require access to entities at remote 
nodes. Furthermore, some of those transactions will have 
to transfer data between nodes. 

2.2.2. System Parameters 

The system parameters describe the computer system or 
database system at each node and are very similar to the 
system parameters of the centralized database model 
described in Chapter 2. The system parameters are summar¬ 
ized in Table 3-2. 

The NGRAN parameter is the number of lockable 
granules at each node of the distributed database and is 
identical to the 'JGRAN oarameter of Chapter 2. The oaram- 

Table 2-2 System Parameters 
Parameter Tescr i rt i_ot 

NGRA’.' number c-f lockable urits of ere node 

of the database 


CPUR ME 

C PM 

time 

to 

pr c-c ess 

ere 

er t i t v 

I o >■ A T E 

I/O 

time 

to 

or ;.cPS s 

cr e 

er ti tv 

LCP If.ATE 

CPU 

time 

tc 

process 

or e 

leek 

LI OR ATE 

I/O 

time 

to 

process 

ore 

1 cc k 




eter was varied from 1, rcpresertirr or e lov.k at, eat n 
node, ud to DBSIZE, represer. ti nr, ore lc.v.k per entity lr 

the database. 

The CPURATE and IORATE determine the cost to process 
one entity in the datahase and are also icier, tical to the 
parameter in the centralized database model. For these 
experiments, the CPURATE and TORATE were both equal to ' 
time unit. This scenario simulates a system with a bal¬ 
anced load between the CPU and I/O requirements. Also 
under this scenario, ore time unit of the simulnt.io: car 
be thought of as the time required for ore I/O operatior , 
i.e., about 30 milliseconds. 

The LCPURATE ar.d LIORATE parameters, the costs to set 
and release ore lock, are also identical to the parameters 
in the centralized database model. For these exnerimer ts, 
the lock CPU rate was ore tenth the entity Cpu rate , :.f .. 
0.1. Under the scenario mer.tiored above, this miqht 
represent 3 milliseconds to set ar ,i role ?sc a leak. The 
LIORATE was zero, simulati r •’ a system where all 1 are 

kept i r. main memory. 

Note that NOR Ah, L0P'’-A7E. LIORATE ar r t.E 7 ". V T ( fr - 


the previous sec-tior) are 1 


. i v :«*' v (* v T' u s f? n 


of the cor currer c v ccr tr -1 al e : r i •: h“ s . As d : t i or al oar r - - 
ters relevant, to the individual or r currer c v ccrtrcl algo¬ 


rithms are introduced ir the seotior desc-rihir q th 
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algorithms. 


2.3.3. Network Parameters 


The network parameters determine the throughput and 
bandwidth of the network as well as the CPU resources 
required at each site to send and receive a message. The 
network parameters are summarized in Table 3-3. 


The number of nodes in the network, set by the NNODES 
parameter was varied from two to eight. 


The message rate parameter, MESRATE, is the length of 
time it takes to send a simple message (i.e. a non-data 
transfer message) from one node to another. Typical 
values for this parameter ranged from 1 through 10. A 
value of 3, for example, would represent a high speed net¬ 
work, where, under the interpretation mentioned in the 
previous section, it would take about 90 milliseconds to 
Table 3-3 Network Parameters 


Parameter 


Descript ior 


NNODES 

MESRATE 

DATARATE 
MES 5 n',., ! T 

MESIDEATE 

MESC^'JEf-TE 


The number of nodes or sites in the network 
The time units a message must stay or the 
network 

The time units to transfer an entity 

The number of simultaneous messages cr 

bandwidth of the N e t w o r k a r a g e r 

The I/O time required by a node to serd or 

receive a message 

The CPU ti^e required by a rode to ser A or 
a message. 




receive 


deliver a message. A value of 10 implies it would take 
about 300 milliseconds to seed a message, about the time 
required or the ARPANET (KLEI761. 

The DATARATE, together with the MF.SRATE parameter, 
determines how lorg a data trarsmissior. message will take. 
If E is the number of entities to be transmitted, then the 
data transmission message would take 

MESRATE + E * DATARATE 

time units to be delivered. If an entity is a 512 byte 
page, and an ARPANET like file transfer at 50,000 bits per 
secord is assumed, it would take about 0.1 seconds to 
transfer 1 entity. On the other hand, or a three 
megahertz speed network, it would only take about .0015 
seconds. Many of the simulation exDerimerts used and 
"optimistic" DATARATE of .05 time units. Other simulation 
experiments used DATARATES of .1, .25, and .5. The MES¬ 
RATE term is included in the above time to represent the 
initialization message which often must precede a network 
data transmission. 

The MESBD'VT parameter determines the bandwidth : f the 
network manager. As explained in. section 2.2, at most 
MESBDWT messages in the network queue are serviced ea>. h 
time unit. For lightly loaded retworks, it is reasonable 
to assume that the bandwidth is unbounded [‘<LEI76] and 
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tmt a s" umnl i cr. i s ir fact m a d o it 'nest of the simulatior. 
ex per imer ts . The results of varvirg that parameter are 
also presetted. 

The MESIORATE and MESCPPPATF. parameters represent the 
resources required at each rode to send or receive a mes¬ 
sage. For these simulatior results, the MELIORATE was 
zero, simulating that the orocessir of all messages is 
handled ir: the main memory; and the MESCPURATE has a value 
ranging from .01 to .3 time units; or ir. the canonical 
i r. ter nr o t a t i or from .3 to 9 mil 1 i secor d s . For the most 
part, the lower bound or MESCPURATE was used, simulating a 
very low (and optimistic) overhead message processor. 

2.3-^. D a ramete rs 

The quartities to be measured cr. the output parame¬ 
ters are summarized ir. Table 3-^. These measurements 
include all of the measurements included ir. the central¬ 
ized database simulatic-r and some other parameters unique 
to th,a distributed model. 

The first eight output parameters are identical to 
the output parameters discussed ir Charter 2. The TCPU 
and TIC parameters refer to the r umber of simulatior time 
units durir •- which the CPU arm: I/I' servers for all of the 
network rodes were went busv. The LQCKCPU and LOCK 10 
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Table <~w 


1 1 

■ :' : 1 it : ,>•”<•• t •">r 
Parameter Desor : 

Loc- al 

TC.PU 
TIO 

LOCK C P'J 
LOCK I 0 
TRANCOM 
AVtiRRKS 
USLPULCPLJ 
USEFUL 10 

Distributed 

MESCPU CPU overhead for r otwrrk mossmces 

MP'S 10 I/O overhead for r otw* t k inssn tc*s 

TMF.SS The total number of a^ssia-o ?. j r t 

LMF.SS The r.umhcr of Loc k re ! a ted m e s s a ~ s s.-rt 

parameters refer to the number of time ur its th rt rt!Sp<\ 

tive servers were busy mar-ar, i r:<t looks. The TRAt'CC’-’ naram 

eter is the total r umber of transactions ecmoletoi at th 

end of a simulation rur . Note that a distributed * ■ :'u 

tier’, regardless of the number of ccrresorr i i r * 'LAY 

trar.sacticr s , is counted as oi e trar sect i-. r . The AYLPLP 

parameter measures the average number of time ur its i 

takes for a trar sat tier to «. .mr 1 •'>1 ••. For d i . 

tr nr sac t ior s , the ressrr 1 1 •> ref-:-- s t r 

erc-e between wher a *.ST~R t’'v on. * i - > ♦ . - rt • • •• • f 

per d ir m queue ar d wher that tr-.-r r ; t; - r le. ,.-r t • •» • • v w. r 

dore queue. 

The useful ccm r iter it i 1 : .■a t . - r - . '' r P Pf 


Total time t.to CP" rv-'-r was a, •; v 
Total time t(r* T /•’ server was <k l: ve 
CPU overhead f r 1 », 1 : i r ; 

I/O overhead for IcoVir ■’ 

Number of trar r.u ti •,.! s o. ■m , 'l ete-i 
Aver a r, e resort se time 
CPU time for ore-, essir •• trar sect: • r> 
1/0 time for processir - trar ••■u t i r r 


US'FULIO , 


refer’ 


to the 


resourv. 


; r r> - 






processing. These measurements were not used for con¬ 
currency control or for message processing. Note that 

TCPU=USEFULCPU+LOCKCPU+MESCPU 

TIO=USEFULIO+LOCKIO+M£SIO. 

The MESIO and MESCPU parameters refer to the time 
required by the I/O servers and CPU servers at the various 
nodes to process messages. Note that a message must both 
be sent and received, so that the I/O and CPU costs to 
send n messages are r*2*MESI0RATE and n*2*MESCPURATE 
respectively. This cost is also independent of the mes¬ 
sage length. Thus, for a data transfer message, this cost 
represents initial set up costs to actually transfer data 
to the network. No additional local costs for the data 
transfer are incurred. In some systems considerably more 
overhead would be incurred for data transfer. 

The TMESS Darameter represents the total number of 
messages sent over the network. The LMESS oarameter is 
the number of those messages which were sent only for con¬ 
currency control reasors. The messages, called 'Lock' 
messages, are discussed when the cor.currency control algo¬ 
rithms are introduced. 
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2.4. T ypi cal S c-er arios 

The simulations were ruri with the parameter settings 
shown in Table 3-5. The local parameters are identical to 
the parameters in the centralized database simulations and 
for the most part were rot varied. The initial settings 
of the distributed parameters are designed to study the 
concurrency control algorithms under a basically free arid 
unlimited network. Later alternate parameter settin.es are 
used to study the effects of network limitatiors or the 
different concurrency control algorithms. The results of 
those experiments are reported in section 4. 

In the next section, the four concurrency control 
algorithms simulated are described and additional parame¬ 
ters required for those algorithms are introduced. 

3. DISTRIBUTE D CONCURRENCY CONTROL 

The distributed database eerourrercy cortrol algo- 


rithms car be 

divided 

into two 

g o r e r a 1 

c las 

site 

concurrency 

ccrtrol 

[ A L ? B 7 5 , 

yE N A 7 R 1 

ar d 

ized 

corcurrer cy 

c c r t r c 1 

r q r n > - 7 ■? 

ELLI 7” , 

0 p A Y 


In the primary site cor currer cy cc r trol sc hem or f:r -• 
distributed database, ore site is chosen to er fence a rr _ - 
cessir.g schedule equivalent to a global s*»r ializnr i :r : f 




Table 3-5 Typical t, ’ir'.T:oter Settings 


Par a m «■> t <• r 

S 0 11 i r r 

Local 

I r t.PM'i ''t at; 0 1 

NT RAN 

10 


10 trap, s at each rode 

DBS I 7 f 

10,000 


10,000 database entities 
at eai.h rode 

AM FAN 

5 


0.05% of DBSIZE 

BMP AN 

250 


2.5% of DBSIZE 

ALP!! 

. 1 


10% of trar.s are lar^e 


0 


All trar.s are small 

LKPLMT 

1 


Well-nlaced locks 
(used with ALPH = .1) 


2 


Randomly placed locks 
(used with ALPH = 0) 

CPU R AT 1 ' 

1 


30 msecs 

IORATE 

1 


30 msecs 

LC PUR ATE 

. 1 


3 msecs 

LIORATE 

0 


Locks in main memory 



Distributed 

PREDIST 

. 1 


10% of the transactions 
are distributed 

PRETRAM 

. 40 


40% of those require data 
tran sf er 

PREDATT 

l r> 

CM 


25% of entities touched 
by the transactors are 
in fact transferred 

NSLAVES 

5 


A distributed transaction 
runs at all nodes 

NNOD-.S 

6 


Six rodes ir the network 

MFSRAT r 

3 


Hish speed retwcrk 

DATA. RATE 

. 05 


fast data trar.sfer Network 

>/ r 5;7 

00 


Lightly loaded retwork 

MRS IOR ATE 

0 


Messages bardie'' i r c 0 r r 

MESS PUR ATE. 

.01 


.3 msecs (very rrtmistt.) 


all 

of the 

trar sact.ic.r s rur r ir a at 

all sites. 

Two 

stra 

i"ht forwar 

d i m r 1 em er tat 0 r s of a 

d r: m a r y s 

i te 

model 

are 

tr eserted 

ir sectors 3-1 ard 3.2- 

Basical 1 

* » 

if a 

prim 

a r v site 

handles all c orcurrore \ 

• c.or trol , 

the 

same 


algorithm used for a cet.trali7.ed database 


car be used for 






the distribute d at n h n r:■ ■ . 


In the decor tr al i •/*■»■! c c.r ^ error cv c.t’r'.l sc :•»' 
each site maintains its o«r leeks for that silo' - p - > si: 
of the database. However, a dead lot V. i c: is ! : r * re i 
can exist ir: the network ever, though r.o dea'il ■'ck i yd 
exists at any giver; node. For example Trar tier 1 ca 

be blocked at node i by Trar.so. tier ?, At ro *.<■ , h. w 
ever, Transaction 2 can be blocked by Trar sad. in* 1 
Although no deadlock exists at either rode i or i, roithe 
Transaction 1 r.or Tran sac tier ?. car be c ompl odd . Tv 
mechanisms and their simulation imnlemer.totioi r far ion’ 
irg with this deadlock problem are presetted it sec tisr 
3.3 and 3d. 


3.1. Primary Site Model 1 


The concurrency cor trol mechanisms ir both. the pri 
mary site models require the following charges to the rod 


model shown ir: figure 3-2: 


When ar y trar.sac tier ( Ucsl : r 
per dir g iueu n , a rich* 1 Irek re 


node selected as the 


ther waits r 


‘ . ’ \ f? ’ .3 0 , 4 n 7 ]_ 


until all of its 1 c <. ks >*-rt •.• 




KVa* ■ 






2) When a global lock grant is received, the transaction 
can proceed to the I/O, CPU and data transmission, 
queues as before. At this time, a MASTER transaction 
starts its corresponding SLAVE transactions. 

3) Upon receipt of a "SLAVE create" message, a new tran¬ 
saction identical to the MASTER transaction is placed 
directly on the I/O queue. 

*0 As in section 2.2, a MASTER transaction waits or. the 
Network done queue until it has received "SLAVE com¬ 
plete" messages from each of its SLAVEs. At this 
point, a MASTER transaction sends a "global lock 
release" message to the PRIMARY site and is recycled 
back to the pending queue. 

5) In the PRIMARY site model, a SLAVE transaction reed 
rot wait or the Network done queue; it car. simply 
send its "SLAVE complete" message and leave the sys¬ 
tem . 

Note that the "global lock request", "global lock 
grant", ar. d "global lock release" messages are all 
included in the lock message court. Also rote that the 
"global lock request" in eludes t.h? lock requests for all 
of the SLAVEs. 







In the primary site model, the nodes are considered 
to be numbered zero through NNOPFS - 1, For each node, 
there is a "blocked" queue and a "locks held" queue as 

shown in figure 3-3. 

When a "global lock request" is received, the PRIMARY 
site lock controller goes through the following steps: 

1) Determine which nodes will be used by the requesting 
transaction. 

2) For each node, i = 0,...,NN0DES - 1, see if this 

transaction requires locks; if not, proceed to the 
next node. If so, request the locks (identical to a 
lock request in Chapter 2) required at this node. 

3) If the locks are granted, record this fact or the 

"locks held" list for rode i ar.d repeat step 2 for 

nodei+1 . 

4) If the locks are denied, Diace the trar saltier or the 

blocked queue for node i, recc-rdirg the bl kir .t 
trar.sactior which is or the "locks held" aueuo frr 

this node, 

5) Wher the locks at all of the required redes are 

granted, a "global locks grartel" message is sort ‘ - 

the originating site. 







Figure 3-3: 

























When a "global lock release” is receive!, the p H IM A R Y 
site lock controller removes the correspor iinir, trar. r.'n ti'-r 
from each of the "lock held" queues. Ary trarsootier 
which was blocked at node i by this trar sootier is res¬ 
tarted at step 2 for node i, in the above algorithm. 

The following observat ions should be noted. First, 
deadlock is impossible, since the locks at the different 
sites are always acquired in a fixed order. Sec ord, LOCAL 
transactions will only be involved with locks at their 
originating sites. Third, note that a non-local transac¬ 
tion can wait for locks at ore node while holding looks at 
a lower numbered node. 

All of the locking costs are absorbed by the primary 
site which also has a normal load of transaction process¬ 
ing. The use of the CPU and I/O servers by the primary 
site control mechanism has a preemptive priority over 
transaction processing requests. In other words, if there 
are global lock releases or requests, the PRIMARY site 
first has to serve those requests before it car process 
any trar, sactior s. If serving those requests t i-m-s m: re 
than, ore simulation time unit, no trar. sac ti;r pr:o.essirm 
takes place during that time urit. 
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3.2. Fri_ma_ry Site Model 2 

The activities at each site of the distributed data¬ 
base are identical urder this model and the previous pri¬ 
mary site model described above. The only difference in 
the two models occurs in the Primary site lock control. 
In this model, there is only ore blocked queue, although 
there is a 'locks held' queue for each node. 

When a "global lock request" is received, the PRIMARY 
site lock controller goes through the following steps: 

1)-3)Same as in previous primary site model. 

*0 If the locks are denied, release all of the locks 
held for lower number nodes, record the blocking 
transaction and place this transaction on the single 
blocked queue. 

5) Same as ir the previous primary site model. 

When a "global loci': release" is received, the PRIMARY 
site ccrtrcllor again releases the locks held at each 
rode. Ary tr sr ssetior which was blocked, is restarted at 
step 1 cf the above algorithm. 

This node! differs from the previous model in two 
ways. The mair difference is that no transaction car hold 


1 ;' •: 

locks at ore rode while wnitirg for locks fro- ar other 
r:ode. This difference "to nr 5 that trnr sac tier s requ j r ir a 
fewer number of nodes, (i.e., local tr ar. sac t. i or s ) have- nr 
implicit priority over transactions requiring loc k<- at 

more nodes. 


3.3. W ound -Wait Model 

As previously mentioned, decer’tral i zed cc.r currency 
control requires a mechanism for resolving deadlock. Ir: 
this section an extension, of a "wound-wait" scheme 
[ROSE77] for resolving deadlock is discussed. First the 
original algorithm in [ROSF77] is presented, followed by 
two extensions. Finally, additional charges ir: parame¬ 
ters, relevant to the "wound-wait" algorithm are reviewed. 


3.3.2* O rigin al Wourd -Wa i t Algorithm 


In [ROSF77], the trar.sactior model is slirhtly dif¬ 
ferent than the ore presented ir. this chanter. A trar sec¬ 
tion is viewed as a prcc«ss which is iritis-tod a*, .re r:i- 
and moves from rode to rode ir the course of its r^oc or-?, 
ir.g. At any ir. star ce the process is cor si der ed a., toco s' 
or.* node ar.d ir active at all other : odes that :t h ; 


visited. 


Ur.dor the wour ii t algct ithm, a unique number, 
as sirred to each prc-coss or li-ar sactior: , is obtained by 
cor c a ter at i r. g a startin’ time with the node number at 
which the process is initiated. (The algorithm does not 
require that the clocks which generate the time stamps be 
perfectly synchronized. However , some close correspon¬ 
dence with the "real" time would be desirable. In 
[LAMP77], a sufficient algorithm for keeping clocks at 
nodes in a network reasor able synchronized is presented.) 

Suppose Tran sac tier 1 requests locks held by Trar.sac- 
tior 2 ar.d that timestamp 1 and timestamp 2 are the unique 
numbers associated with the two transaetiors. Then the 
following steps are taker:: 

1) If timestamp 1 < timestamp 2, then Transaction 1 is 
"older" thar Transaction 2. In this case, Transaction 
2 is wounded and Transaction 1 waits. 

2) If timestamp 2 < timestamp 1, then Transaction 2 is 
"older" thar Trar sac-tier 1. Ir. this case. Transac¬ 
tion 1 simply -..aits. 

If Trar. sac tirr 2 is wcu: del, a messare is ser t tc all 
si te r visited by Trar 2 . If termer at icr :f Trar - 

s a c t i: r 2 has alread y h • j r , t r, e wour 1 is igr cred , sir.ee 
Trar sac tier 2 will see: release its leeks ar d Transacticr 
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1 car proceed. -If Tran sac t ior 2 has not be.'ut trie term i- 
natior process, it is aborted (or killed) ar.d restarted. 
Again, the locks held by Trar.sactior ? are released ar d 
Transaction 1 can proceed. Note that in order to prevert 
cascading abortions of trar.sactior s , all locks for a giver: 
transaction are held until that trar.sactior. terminates. 

A natural modification to this algorithm is suggested 
in [ROSE77], where Transaction 2 is rot aborted ar i res¬ 
tarted unless it is actually in or enters a waiting state. 

This algorithm provides a consistent concurrency ocr- 
trol for which every transaction terminates. Cor. si .ter cy 
is maintained because a tr ar. sac ti or holds all locks until 
it has completed. Thus, two-phased looking ;5 insured. 
To see that every transactior terminates, rote that at arv 
giver. time, due to the uniqueness of the timestamp, there 
is exactly ore "oldest" transactior.. That trar sootier oar 
never be wounded ar.d thus must terminate. At that point, 
there is a new "oldest" trar.sactior which els: must ter¬ 
minate. A transactior retains its original t i -or t ever 
if it is restarted. 

3.3.2. Sim ula tion Imolemer taticr 

To apply the above algorithm to the distri: ute 1 »r-ar - 
sac tier processing discussed in this < harder-, it - J; -,. 
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first be noted that a wounded transactior can be active at 
more than ore site. Thus, the decision to abort and res¬ 
tart a transaction might be initiated at several sites. A 
wound or kill message for an already killed trar:sactior is 
simply ignored. When a transaction is restarted a 'cycle 
number' is incremented. The cycle number, initially zero, 
is included ir. the message addresses so that the restarted 
transactior does not erroneously receive an old wound or 
kill message. 

A second simple modification to the [ROSE77] algo¬ 
rithm was also made. A transactior receiving a wound mes¬ 
sage is rot restarted unless that transactior is blocked 
by or becomes blocked by a transactior. that the original 
transactior: cannot wound . In other words, a wounded tran¬ 
sactior. must be restarted if and only if it is blocked by 
ar: older trar: sactior:. Note that this algorithm still 
resolves any potential deadlock and all transactions must 
eventually terminate. 

Theorem: This modified wound-wait system still preserves 

persistency and every orecess terminates. 

Proof: The database cor sistercy is preserved since the 

lockir s is still two-phased. 

Every process will term!: ate, since a deadlock cycle 
carnet exist ir the wait-for graph. The wait-for graph is 









a directed granh where the r :des re:w<-• r.er t tr a: r>i; ‘ i r s lr 
the system. An arc from ere node to another imp'. i er that 
the f’rst rode reoreser. ts a transact] or that is bio. k<-i by 
the trarsactior represented hy the sec ord rode. 

Suppose a deadlock cycle existed in the rrraph betweer 
nodes T^,...,T r (i.e., is blocked by T^ , is blocked 
by is blocked by , and is blocked by 

T.j ). Without loss of e’er er a 1 i t y , assume is the oldest 
transaction. Then must wound T^. 

If T 2 can. wound , it does. If not, T ? is aborted and 
the deadlock no lor.e,er exists. 

Similarly, if any cannot wound T i + 1 , it must be 

aborted . 

If all of the (i = 2 ,...,r) are wour ded, so is T . 

But T r is blocked by and cannot wcur:d T. because of our 

assumptions. 

Thus, T must be aborted an i restarted an d the iea :' c>c 
cycle is broker. 

i _ r . r . 

To implement the at; .• e air* or i i h~ 5 >,•«r al •- - * ■ •• . v - _ 

tiors to the simulator were hirst, t .c - i 

time of each tr=r sactirr w •» s •- ear * t • •« : ev 

ir.sur ir q that all tr an sac 11 s arrive : v 1 or e ♦ 1 





unit apart. Thfe arrival time, concatenated with a node 
number, in the least significant bits, is the unique 
timestamp associated with the transaction. In addition, a 
cycle number is added to each transaction in order to 
insure that a restarted transaction is riot wounded or 
killed by a message intended for an earlier incarnation. 
When a transaction (SLAVES excepted) is first placed on 
the pending queue, the cycle number is initialized to 
zero. Messages are only delivered to transactions with 
the correct cycle numbers. Messages destined for earlier 
cycles are simply discarded. A SLAVE transaction takes on 
the timestamp and cycle number of its corresponding MAS¬ 
TER. The following steps are now followed by a transac¬ 
tion. . 

1) A transaction leaves the pending queue. If the tran¬ 
saction is a MASTER and this is the first time this 
incarnation has left the pending queue, "SLAVE 
create" messages are sent to the appropriate nodes. 

2) After leavirg the pending queue, a tr an sac ti or. 

requests the locks reeded at that site. If the locks 
are granted the trnrsaetiot proceeds to the I/O, CPU 
and data trarsmissicr queues. If the leeks are 
denied, the trarsacticr is placed on the blocked 
queue for this node. Let Tl be the requestirg trar- 



saction and T2 be the blocking tr an sac- 1 1 or 
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respec¬ 
tively. If both T1 and T2 are distributed transac¬ 
tions (SLAVES or MASTERS) and T1 is older than T2, 
transaction T2 is "wounded". If T1 is younger than 
T2 and has been previously wounded, T1 is killed. 

3) Once the locks are granted, the transactiors proceed 
on the I/O, CPU and data tr an smi ssior- queues ns 

before. 

4) A SLAVE transaction sends a "SLAVE complete" message 
to its MASTER and waits or the Network dore queue for 
a release locks message. A MASTER transactior waits 
on the Network done queue until all of its SLAVES 
have completed. 

5) When all of the SLAVEs have completed, the '-’ASTER 
sends a "release locks” message to all of its SLAVEs, 
releases its locks, and becomes a rew transact)or or 
the pending queue. At this point the trar sac tier is 
considered dore. When a SLAVE rec eives t >,•-> "release 
locks" message, it releases i‘s locks ar : ! *-> a v s the 
system. 

6 ) When ary transaction releases its 1'cks, the 

correspor d in g blocked transactions (if ary) are 
placed at the front of the oerding queue. 
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When a transaction is wounded, "wound" messages are 
sent to the MASTER and all SLAVES. When a transaction 
receives a wound, it is flagged as wounded. If the tran¬ 
saction is already blocked by a distributed transaction 
with an older timestamp, the wounded transaction is 
immediately "killed". 

When a transaction is killed, "kill" messages are 
sent to the MASTER and all SLAVES. Both types of transac¬ 
tions release their locks and blocked transactions are 
placed on the front of the pending queue as in step 6 
above. Any time spent or: the I/O or CPU queues is counted 
in a "lost time" total. At this point SLAVE transactions 
leave the system. A MASTER transaction increments its 
cycle number and is placed on the back of the pending 
queue for a reincarnation. 

A few observations should be made. First, in step 2, 
only if both transactions are non-local, does a potential 
wound have to take place. If the blocking transactior is 
local, it is guaranteed to firish since it has preclaimed 
all of its locks. If the blocked transactior is local, it 
car: hold r.o locks at ether sites ar.1 thus ro lead lock can 


occur. 


Second, when a transaction is restarted, it is placed 
on the pending queue behird any trarsacticrs that it 


blocked. In particular, it is placed behird the 








transactior that caused the original wound. Thus, the 
same wound will not occur again. 

Note that the extra "release lock" messages to the 
SLAVES are not present in the primary cor.currency control 
models. They are not needed in those models because all 
locks are held (and thus released) at the primary site. 

3.3.3. Addi tion al Par ameters 

Four additional output parameters were recorded in 
the simulation model for the "wound-wait" corcurrercy con¬ 
trol. In addition, new types of messages are classified 

as lock messages. 

The four output parameters are for the number of 
transactions wounded (NTRWOUND) , the number of transac¬ 
tions killed (NTRKILL), and the lost time attributed to 
killed transactions (DLOSTIO and DLOSTCPU). The court of 
the number of tran sactions wounded, NTRVQUND, is made only 
when a cycle of a given MASTER receives its firs*, wound. 
Thus, even though the SLAVES all receive wound messages, 
the wounding of a distributed trar sac tier ir crlv irtei 
once. 

Similarly, the ccurt of the number of t r a n s . 1: : t r 

killed, NTRKILL, is made only wher a M A S 7 E 0 receives its 

first ki 11 . 
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The DLOSTIO and DLOSTCPU parameters record the number 
of time units of I/O and CPU service respectively that.a 
killed transaction has received. How much time is actu¬ 
ally lost depends on both the queue the transaction is or. 
and the processing completed at that queue. Note that the 
definition of the total I/O utilization, TIO and the total 
CPU utilization, TCPU also changes: 

TIO = USEFULIO + MESIO + LOCKIO + DLOSTIO 

TCPU = USEFULC PU + MESCPU + LOCKCPU + DLOSTCPU. 

In the "wound-wait" concurrency control algorithm for 
a decentralized database, "WOUND", "KILL” , and ’’lock 
release" messages are all counted as lock related mes¬ 
sages. The lock related messages used in the primary site 
models are no longer relevant. 

3.M. SNOOP Model 

A second decentralized concurrency control algorithm 
uses a 'SNOOP' [STO','78] or a global deadlock detector 
[GRAY73] was also simulated. One problem with the 
"wound-wait " algorithm is that transactions may be killed 
and restarted needlessly. While the algorithm is suffi¬ 
cient to prevent deadlock, it may be too conservative. 
Transactior. 1 could be blocked by the younger Trarsactior 




■ mi r 1 i. 
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Transaction' 2 could be blocked by the older Transac¬ 
tion 3, which can in fact complete. Even though r.o 
deadlock is present, Transaction 2 would still be res¬ 
tarted . 

In this section, an algorithm is described which res¬ 
tarts transactions only when an. actual deadlock occurs. 
In section. 3-^.2, the implementation of that algorithm in 
the simulation model is presented. In section 3.^.3 
changes in the simulation, parameters are discussed. 

3 • ^. 3. • S NOOP Algorithm 

In [STON78] a decentralized algorithm for concurrency 
control is presented. Each node or site in the distri¬ 
buted database is responsible for local corcurrercy cor- 
trol for the portion of the database at that site. If two 
transactions conflict, the local concurrency cortrol sends 
a message about this conflict to a designated site called 
’ The SNOOP’. 

—---Jb 

The SNOOP then detects deadlock by ar arc I vs is of the 
"wait-fon” graoh generated by ail su».h mossa-*°s. If a 
deadlock cor.ditior is detected, a victim is ricKed to be 
killed and restarted (a reir c arrati :r ' . Note that when j 
transaction has completed, the S*.'0"P must also be notified 
so that the appropriate entries ir the "wait-fc,r" graph 



can be cleared. ■ 


The same basic idea was also suggested in [GRAY78] 
with several modifications. One modification is that a 
conflict message is only sent to the SNOOP if the blocking 
transaction is directly waiting on a response from another 
node or is blocked (directly or indirectly) by some other 
transaction that is waiting on a response from another 
node. 

Another suggested modification is to only send such 
conflict messages and check for deadlock periodically. In 
this manner the system overhead for both handling lock 
messages arid checking for deadlock can be reduced at the 
cost of delaying the detection of an existing deadlock. 

3.« .2. Simulation Imp lem entation 

The 'SNOOP' simulation model is very similar to the 
wound-wait model. The following steps are taken in the 
'SNOOP' model. 

1) Same as "wound-wait" model 

2) Same as "wound-wait" if the locks are granted. Sup¬ 
pose the locks are denied and T1 is the requesting 
transaction and T2 is the blocking transaction. If 
both T1 and T2 are distributed transactions (SLAVES 




or MASTERS), a corflict message is sent to ore of the 
sites designated as the SNOOP. 

3,4) Same as "wound-wait" model. 

5) Same as "wound-wait" except that when a MASTER tran¬ 
saction is done, a "clear snoop" message is sent to 
the SNOOP. 

6) Same as "wound-wait" model. 

The SNOOP maintains a global "wait-for" directed 
graph. Each rode represents a blocked or blocking tran¬ 
saction. An arc from node 1 to node 2 implies that the 
transaction represented by node 1 is blocked by the tran¬ 
saction represented by node 2. When a corflict message is 
received, a node for each transaction (if ore doesn't 
already exist) is added to the graph along with the 
appropriate arc. At that point, the graph is searched for 
a cycle beginning at the node for the blocked transaction. 
If deadlock is detected, the yourgest (determined by the 
unique timestamp) of the two trarsactiors involved with 
this conflict is declared a victim ar.d killed. The fact 
that a giver, cycle of the victim was killed is remembered 
by th« SNOOP. 
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The killin’ of a transaction is identical to the kil¬ 
ling of a transaction in the wound-wait algorithm. The 
SNOOP sends a message to the MASTER and its SLAVES. Both 
tvoes of trap sac tiers release locks and record lost time. 
A MASTER transaction is reincarnated as in the wound-wait 
model . 

Note that it is necessary that the SNOOP remembers 
both killed and completed tran sactior s for a given period 
of time. It is possible that the SNOOP could be notified 
of a conflict involving a killed, or completed transac¬ 
tion. In these cases, the conflict occurred before a node 
received the 'kill' or 'release locks' message. In the 
case of a killed transactior, a false deadlock could be 
detected. In the case of a completed transaction, an 
extra rode would simply clutter the wait-for graph. If a 
killed or completed transaction is involved in a conflict 
message, the message is simply ignored at the SNOOP site. 


The cycle 

r umber 

is needed 

by the SNOOP to 

d i s t i r. - 

g uis h betw ee r 

" 0 S ? .1 v c s 

mear t for 

different ir.carratiors of 

a t. r a r s a c t i c r . 

If a 

conflict 

message arrives 

with a 

h i r. h e r c y c 1 e 

r umber 

than the 

cycle number of 

a killed 

red", the ki 11 

e d rede 

is removed 

and a new rode 

ir ser te d 

ir. the graph. 

If a c 

o r f 1 ic t me 

ssage arrives with 

a lower 


cycle r umber than the oorresror lire, : ode in the graph , the 
message is sin civ discarded. Such messages are obsrlete. 



Also rote that in the case of d<_> h J lock, the vut! m i s 
chosen from among the two nodes irvclved ir: this cot flict. 
This choice is guaranteed to break any deadlocks sirce the 
graph is assumed to be deadlock free before the latest arc 
was added. This victim may not be the optimum victim for 
backout. However, if a different victim were chosen, the 
other parts of the graph would still have to be searched 
for other deadlock cycles. 

Finally note that all conflicts between r.or.-loeal 
transactions are sent immediately to the SNOOP. As previ¬ 
ously mentioned, it is suggested that the corflict. mes¬ 
sages should rot be sent unless the blocking trar.sacticr 
actually enters a "node wait" state. However, in this 
model, both MASTER and SLAVE transactiors will eventually 
wait for messages from other nodes before they release 
their locks. Since that 'node-wait' state is inevitable, 
the corflict messages are sent immediately. 

3.^.3. S NOO P P arameters 

As with the ”wour d-wait" ala-rith" , eevr-~1 r ew 
parameters are introduced and the defit it: or of 1;.-: mes¬ 
sages is char ged . 

The cost to check for decs!cck is very ey:er r \ ve ; 
often this cost is much rreater the c : -1 t: c - r -t a 
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simple lock [GRAY731. A new network input parameter, 
SNOOPRATE, was added to the simulation to model that addi¬ 
tional cost. Every time a conflict message is received by 
the SNOOP, SNOOPRATE time units are added to the locking 
costs at the SNOOP node. Note that conflicts involving 
killed or completed transactions are not included. In 
most of the experiments, a SNOOPRATE of .5 is used. In 
the canonical interpretation this value represents about 
15 milliseconds or about 5 times the cost to set a lock. 

The NTRKILt, DLOSTIO, and DLOSTCPU parameters from 
the wound-wait model are also included in the SNOOP simu¬ 
lation. However, rather than the NTRWOUND parameter, the 
SNOOP model records the NUMCONFLCT parameter, the number 
of actual conflict messages received. Again, conflict 
messages for already killed or completed transactions are 
not included in this count. 

The lock messages in the SNOOP model are the 'con¬ 
flict' messages, the 'kill' messages, the 'release locks' 
messages and the 'clear SNOOP' messages. 


4. RESULTS AND . DIS CUSSION 

The results for the distributed database si'nu la tiers 
are presented in this sectior . In the first seeticr we 
present the results for the parameter settings for the 
canonical scenarios. Subsequent sectiors review the 
effects of varying the number of SLAVES for each distri¬ 
buted transaction (NSLAVES), the number of nodes in the 
network (NNODES), and the percent of distributed transac¬ 
tions (PREDIST). 

In section 4.5, the results of varying the network 
parameters are repeated. These parameters are the message 
rate (MESRATE), the network bandwidth (MES8DWT), the CPU 
rate for processing messages (MESCPURATE) and the percen¬ 
tage of data transferred (PRETRAM and PREDAT'D. Finally, 
the canonical cases are revisited in section 4.6 with a 
different network environment. 

The results are reported for each of the four con¬ 
currency control algorithms simulated and the two dif¬ 
ferent classes of transaction sizes. The first primary 
site model, where locks for one site are held while wait¬ 
ing for locks at another site, is denoted "PS1". The 
second primary site model is denoted "PSP" . The notatior 
"WW" refers to the wound-w;it algorithm, while "SNOOP" 
refers to the algorithm with the single global deadlock 






A 




de tec tor . 


Transactions in class 1 refer to transactions whose 
sizes are generated by a hyper exponential distribution and 
well-placed locks are assumed. Transactions in class 2 
refer to transactions whose sizes are mainly small (gen¬ 
erated by an exponential distribution). In this case, 
random lock placement is assumed. 

In the first three sections, an unlimited network is 
assumed in order to study the effects of the different 
concurrency control algorithms on the processing at each 
of the nodes. Beginning in section 4.4, network limita¬ 
tions are introduced to study the effects of the con¬ 
currency control algorithm or. the network resources. 

4.1. The Car^ani_cal Scen ario s 

The canonical scenarios refer to the cases where the 
input parameters have the settings shown in Table 3-5. 
For these experiments, as in Chapter 2 , the number of 
locks (MORAN), was varied from 1 up to DBSIZE and reflects 
the number of locks at each node. One lock implies that 
at each node, only ore transaction can. be active at ore 
time. With 10,000 locks, there is ore lock for each 
entity at each node and transactions can proceed if the 
entities they require are not being accessed by any other 
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transaction . 


Table 3-6 shows the expected rumber of each type of 
message under the canonical parameter settings. Each 
non-local transactior. sends 5 (MSLAVE) slave create mes¬ 
sages and receives 5 slave completed messages. In addi¬ 
tion, 40% (PRETRAN) of the non-local transactions send 6 
(NSLAVES +1) data transfer messages. These non-local mes¬ 
sages are the same for all four concurrency control algo¬ 
rithms . 

However, the four algorithms send different numbers 
of lock messages. In the primary site models, transac¬ 
tions at 5 of the 6 rodes (all nodes other than the pri¬ 
mary site) have three lock messages: "request locks", 
"grant locks", and "release locks". In the decentralized 
models, only the non-local transactions send lock mes¬ 
sages. Those messages include the 5 (NSLAVE) release lock 
messages plus some messages for wounding transactions, 

Table 3-6 

Expected Messages per Transaction 

PS1-PS2 WoW-SNOOP 



Local 

Non-local 

Loc al 

Nor -local 

Non-lock 

Messages 

0 

10+( .4)6 

0 

10+(.4)6 

Lock 

Mesaages 

3(5/6) 

3(5/6) 

0 

5+? (WW) 
5+(5/6)+? 
(SNOOP) 


ki 11 ir:transactions and/or notifying the SNOOP of con¬ 
flicts. In addition, in the SNOOP model, a non-local 
transaction at other than the SNOOP site must send a 
"clear SNOOP’" message when it has completed. 

The results for the canonical scenarios are presented 
for class 1 and class 2 transactions. Figures 3- 1 ' and 3-5 
show the effects of varying the number of locks at each 
node on the USEFULIO for each of the four concurrency con¬ 
trol algorithms. The horizontal axis represents the 
number of locks in a logarithmic scale. The vertical axis 
is the USEFULIO, or I/O resources used in completing tran¬ 
sactions, in 1000 time units of the simulation. Note that 
for six nodes, at most 120,000 time units (NNODES*TMAX) of 
1/0 resources are available. The curves for the USEFULCPU 
measurements were very similar and are not shown. 


*1.1.1_« Class 1 ZL3 r - s s 

Figure 3- f * shows the results for class 1 transac¬ 
tions. For all four concurrency control algorithms, the 
maximum USEFULIO occurred with 500 to 1000 granules. For 
the primary site 2 (PS2) and the global deadlock detector 
(SNOOP) models, the peak occurred at 500 granules. For 
the primary site 1 (PS1) and wound-wait (WW) models, 1,000 
granules were optimal. In either case, with 1% of the 








maximum USKFULIO was reached with 500 or 1000 granules. 

Several observation about figure 3-*i should be 
noted. First, the primary site two model (PS2) achieved 
98% of the maximum USEFULIO with 100 granules and 90% of 
that maximum with as few as 50 granules. Each of the 
other three models required at least 250 granules to reach 
within 10 percent of its respective maximum. Thus, more 
coarse granularity was acceptable in the primary site two 
model. In that model, no transactions held locks at one 
node while waiting for locks at another node. In each of 
the other models this condition was not true. 

Second, the differences in useful computer utiliza¬ 
tions were very small at the optimum granularities, 
although the primary site two model (PS2) did show a 
slight advantage. At lower granularities, the primary 
site models produced significantly more useful computer 
utilization since transactions did not have to be res¬ 
tarted. Similarly, at lower granularities, the SNOOP 
model out-per formed the wound-wait model, since it caused 
even, fewer transactions to be restarted. 

The average response time curves (rot shown) for the 
transactions in class 1, did not consistently favor any of 
the four algorithms. However, at or near the optimum 
granularity (1000 leeks at each node), the decentralized 
algorithms had a better average response time than the 
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primary site 1 model. This result is expect'-.;!, siuo 
local transactions car: be run without network delay. 

Surprisingly, however , the average reaper se time was 
even less for the primary site 2 model. In this case, ary 
gains observed by the local transactions in the decentral¬ 
ized models were more than offset by the extra delay 
experienced and caused by distributed transactions holding 
locks at one node while waiting for locks at anoth -r r ode! 

The exact values of the output parameters observed 
with 500 locks at each node for class 1 transactions are 
reported in Table 3-7. 


Several observations should be noted. At the primary 
site 2 model, the number of transactions completed, TRAM- 


Table 3-7 

Output Measurements for Class 1 Type Transactions 


Measuremer t 

PS 1 

PS2 

ww 

SNOOP 

TRANCOM 

2,688 

3,307 

3,094 

3,029 

AVERRES 

392 

350 

368 

362 

USEFUL 10 

86,056 

87,6*18 

87,518 

87,556 

USEFULCPU 

86,065 

86,335 

87,522 

87,563 

LOCKCPU 

8 * 1 3 

1 ,048 

952 

962 

MESSCPU 

207 

265 

108 

1 03 

TMESS 

9,697 

12,437 

5,408 

5,178 

LMESS 

6,799 

8,329 

1 ,545 

1 ,664 

NWOUNDED 
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NCONFLICTS 

_ 

— 

_ 

68 

NRESTARTED 

— 

— 

1 

0 

DL0STI0 

- 

- 

392 

0.0 

DLOSTCPU 

- 

- 

392 

0.0 




COM, was 10% greater than with the two distributed control 
models and about 18% greater than with the primary site 1 
model. However, the differences in USEFULIO and USEFULCPU 
were not significantly different for the four concurrency 
control models. Thus, the large TRANCOM value was due 
primarily to the fact that the PS2 model favored smaller 
transactions and 90% of the workload included those small 
tran saction s . 

With the other models, larger distributed transac¬ 
tions could block both large and small transactions at 
several nodes while waiting for locks at another node. 
With the PS? model, however, the larger distributed tran¬ 
sactions (which have the greatest probability of con¬ 
flict), would release the locks at lower numbered nodes. 

The LOCKCPU, MF.SSCPU, TMESS and LMESS parameters were 
also greater for the primary site ?. model, since more 
transactions had been completed. 

As expected, message CPU overhead was lowest for the 
decentralized concurrency control algorithms. Also note 
that the ratio of the total number of lock messages sent 
to the total number of messages sent (LMESS/TMESS) is 
about for the orimary site models versus .3 for the decen¬ 
tralized control models. In other words, two-thirds of 
the network traffic was due to concurrency control in the 
primary site models. Less than one-third of the messages 
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in the decentralized models were for concurrency control. 

The expected number of messages shown in Table 3-6 
can be applied to the number of observed messages shown in 
Table 3-7 to determine the exact number of lock messages 
sent by local transactions. In the primary site 2 model, 
for example, 4,108 non-lock messages (TMESS-LME5S) had 
been sent. Since the expected number of non-lock messages 
is 12.4, 311 of the 3,307 transactions were nor-local. 
(Note that this number is consistent with 3,307 total 
transactions and a PREDIST value of 10%.) Thus 2,996 tran¬ 
sactions were entirely local and yet were resporsible for 
7,490 lock messages. 

Notice that a very small number of transactions were 
wounded. In the canonical scenario only 10% of the tran¬ 
sactions were distrbuted and orly conflicts between dis¬ 
tributed transactions could cause wounds. Furthermore, 
all locks are requested at the beginning of a transaction 
and were generally granted. Thus, a transaction is much 
more likely to be blocked by an older transaction, in 
which case no wound is sent. Note that many more con¬ 
flicts than wounds were sent. However, r-.o deadlock was 
detected, so no transactions were restarted in the SNOOP 


model. 




The number -of conflicts in the L'NOOP model was always 
greater or equal to the number of transactions wounded in 
the wound-wait model, since all conflicts between distri¬ 
buted transactions were sent to the SNOOP. However, the 
number of killed or restarted transactions in the SNOOP 
model was always less than or equal to the number res¬ 
tarted in the wound-wait model, since only actual 
deadlocks could cause a restart. In fact, in the simula¬ 
tion results reported in Table 3-7, no transactions were 
restarted in the SNOOP model. 

1*1*C lass 2 Tran sac tion s 

The USEFUL 10 computer utilization for each of the 
four concurrency control algorithms for class 2 transac¬ 
tions are shown in Figure 3-5. Under the randomly placed 
locks with only small transactions, the finest granular¬ 
ity, 10,000 locks in this case, was again optimal. With 
this optimal granularity, as with class 1 transactions, 
only slight differences in computer utilizations were due 
to the concurrency control algorithms. 

However, the wound-wait and global deadlock detector 
algorithms did cor 1 si sten tl y produce somewhat better 
results than the primary site algorithms over a wide 
variety of granularities. In fact, only with fewer than 
50 locks at each rode, were the primary site models 









SNOOP 
PS I, PS2 



No. of locks (log scale) 

Figure 3-5: Productive computer utilization with 
four algoriHints and Class 2 Transact 


ions. 
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advantageous, 

No difference in computer utilisation was observed 
between the two primary site models once the granularity 
became fine enough. This result was true for class 2 
transactions, since the probability of success or a lock 
request was extremely high. Thus, very few of these tran¬ 
sactions waited for locks at one node, while holding locks 
at another node. 

Similarly, once the granularity was less coarse 
(about 50 granules), little difference in computer utili¬ 
zation is realized between the two decentralized algo¬ 
rithms. This result was also realized because of the high 
probability of success or. a lock request. 

Figure 3-6 shows the average response time versus the 
number of locks at each node for class 2 transactions. 
The response time is given in terms of time units of the 
simulation. In the canonical interpretation of the time 
parameter, a resnonse time of 61 would represent about 1.8 
seconds. The dichotomy between the primary site algo¬ 
rithms and decentralized algorithms was again realized in 
these curves. As expected, the decentral i zed algorithms 
produced lower average response times, since local tran¬ 
sactions did not. need to communicate with any other nodes. 

The exact values of the output measurements for 
10,000 locks at each node are reported in Table 3-8 for 


Average response time (time units of simulation) 


IS] 



No. of locks ( log scale ) 

Figure 3-6: Average Response time for four 

algorithms and Class 3 Transactions. 
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class 2 transactions. 


Note that the network parameters observed the same 
ratios of total messages to lock messages as with the 
class 1 transactions. However, the differences in the 
number of lock messages between the primary site models 
and the decentralized models was over 40,000 messages with 
class 2 tran sactiors . With that number of messages it is 
no longer realistic to assume that the network is 'lightly 
loaded' i.e., that the message bandwidth parameter is 
infinite. Restricting the message bandwidth can only 
increase the differences between the primary site control 
and decentral ized control models as will be shown in sec¬ 
tion 4.5. 


Table 3-8 

Output Measurements for Class 2 Type Transactions 


Measurement 

PS1_ 

PS2 

WW 

SNOOP 

TRANCOM 

18,455 

18,461 

19,259 

19,097 

AVER RES 

64 

64 

61 

62 

USEFUL 10 

93,956 

93,280 

97,135 

96,193 

USEFIILCPU 

93,996 

93,319 

97,145 

92,204 

MESSCPU 

1,519 

1,529 

670 

700 

TMESS 

73,977 

74,Pd? 

73,520 

34,852 

LMFSS 

51,594 

51,234 

9,635 

11,093 

NW0UMDED 





NCONFLICTS 

0 

- 

- 

5 

NRESTARTED 

- 

- 

0 

0 

DL0STI0 

- 

— 

0 

0 

DL0STCPU 

- 

- 

0 

0 
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The relatively small d i f f erer u es i: nvora-v res per re 
times between the primary site ar.d decor. tral i reel control 
models, was at first surprising. However, most of the 
delay for the trarssactior s was due to compet i t. i r r for the 
CPU and I/O resources. The network delay time of 2 * ME5- 
RATE time units was not a relevant factor. For example, 
with ten transactions at each node, a local transactior 
was active at a site with 9 other transactions. For class 
2 transactions, the average tranS3ction size was 5. Thus 
a transaction waited for the I/O and CPU resources for 
about 45 time units (9 trars X 5 time un i t. s/tr nr. s) . In. 
addition, the average transactior would spend 5 time units 
using the I/O and CPU resources. 

Thus 55 time units of the average resporse time is 
accounted for without considering lock conflicts or ret- 
work delays. If either fewer transactions were running, 
the transactior; sizes were smaller, or the network were 
slower, the 2 * MESRATE delay would further increase the 
response time difference between the primary site and 
decentralized models. 

The expected number of messages shown in Table 3-6 
can also be used in analyzing the number of messages shown 
in Table 3-8. In this case, 1,859 transactions were non- 
local in the primary site 2 model. Thus, the 16,502 local 
transactions accounted for 4 1 ,505 of the lock mess'ges. 
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Note, however, that the number of lock messages in 
both primary site models is higher than the expected 
number of messages according, to Table 3-6. For 18,461 
transactions completed, 46,153 (TRANCOM * 3(5/6)) lock 
messages should have been sent. This difference was due 
to a slight bottleneck at the primary site. In computing 
the expected value it was assumed that 5 out of every 6 
transactions comnleted would be initiated at other sites 
and thus require the lock messages. However, due to the 
bottleneck at the primary site, 9 out of every 10 transac¬ 
tions were initiated at other sites. 

In the next sections, the effects of variation in the 
input parameters on the above observations are reported. 

4.2. §lj3ve Tra ns act ions 

In a distributed database, not all of the distributed 
transactions require access to data at all of the nodes as 
assumed in the above results. In this set of experiments, 
the number of SLAVES required by each MASTER transaction, 
NSLAVE, was set to 1, 3 and 5. With these settings of 
NSLAVES, a distributed transaction thus accessed data at 
2, 4 and 6 rodes, respectively. The results of these 
parameter settings for class 1 and class 2 type transac¬ 
tions for the four concurrency algorithms follow. 






. ?.1_- C^ass 1 'Trnrsfu tiors 

The affects of varying the number of SLAVES wei'o 
similar under any of the four corcurrency control algo¬ 
rithms. The maximum useful computer - utilization again 
occurred with 500 or 1000 granules regardless of the 
number of SLAVES used by a distributed transaction . In. 
addition, all four concurrency control algorithms resulted 
in similar shifts in the utilization curves as the number 
of nodes per distributed transaction varied. The shifts 
are shown for the SNOOP algorithm in Figure 1-7. 

As expected, as the number of SLAVES decreased, the 
useful computer utilization increased. Although the 
optimal granularity did not change, the number of granules 
required to achieve utilization close to the maximum 
decreased as the number of SLAVES decreased. If' each MAS¬ 
TER transaction had 1 SLAVE, 50 locks resulted in 95% of 
the computer utilization realized with 500 locks. With 3 
SLAVES, 91 % of the maximum utilization was realized with 
50 locks, while only 63% was realized if there were 5 
SLAVES for each MASTER trars action. Thus, as the number 
of remote nodes decreased, the acceptable granularity 
results resembled those observed in Chapter ? for the cen¬ 
tralized database. 



UsefulIO ( x k time units } 





As previously stater!, the other three do i <; 
similarly. In general, varying the Mentor of SLAV!/: for- 
distributed transactions did rdt have a large i.npn i r 
the processing at the nodes. However, tl <- ut 1 1 i rat ) a o< 
the network as a function of the ram her of ro r n-> to r >-dos 
does depend on the concurrency control algor i thm used. 
Table 3-9 shows the percentage of "useful" messages (r .r- 
lock related) for each of the four algorithms. V: ’ n ' ho 
primary site models, the number of lock me:;-.are,-. "t.avod 
constant, but the number of nor -lock messages O'-we; .1 . > 
the number of SLAVES for each MASTER tramoti or . Vith 
the decer-tral ized algorithms, of course, the r ir.'^-r ■!’ 
lock messages decreased as the number of slaves dec rea.-,.- : . 

jt.2.2. Class 2 Tran.sactior-s 

The number of SLAVES for a distributed transactlot 
also had little effect or- the choice of cor currer cv cot- 
trol algorithm or grarul arity for class ? trnrsvii r . 
As in the canonical scenario, the finest gram! u i‘v wia 
again optimal. In the primary site models, tue r < r <-v 
Table 3-9 Useful Network Traffic 




(Nor - loc k 

Me ssages) 


of SLAVES 

PS1 

PS? 

WW 

SNOOP 


9% 

1 1% 

71% 

6h% 


21% 

21% 

71% 

6f»% 


30% 

33% 

711 

6 H% 


1 

3 

5 
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utilization and average response time as a function of the 
number of locks were almost identical for one, three and 
five SLAVES for each MASTER transaction. For the decen¬ 
tralized concurrency control models, those three curves 
were nearly identical with more than 50 granules. With 
fewer granules, more SLAVES resulted in more transactions 
being restarted. In these cases, the computer utilization 
was decreased. However, even with only one slave Der dis¬ 
tributed transaction, performance of the system with class 
2 transactions was still extremely bad with coarse granu¬ 
larity . 

The observations on the network utilization for class 
1 transactions also hold for transactions in class 2. In 
fact, while the number of total and lock messages changed, 
the percentages of useful messages were approximately the 
same. 

U.3. N um ber of Network Nodes 

The number of sites in a distributed database can 
vary. The simulation models were run with 2, 4, 6 and 8 
sites for a variety of granularities. In order to keep 
the other factors constant, the canonical scenarios were 
changed. In all of these experiments, it was assumed that 
each distributed transactior. required only ore slave run¬ 
ning at another site. 




4.3.1,. Class 1'Transact i or s 

With mixed transaction sizes and well-nlrued locks, 
there was practically no difference between the four cot- 
currency control algorithms as the number of nodes ir the 
network varied. Moreover, neither the optimum granulari¬ 
ties nor the shapes of the useful utilizatior versus 
granularity curves changed as the number of nodes in. the 
network varied. The curves all resembled those shown in 
figure 3-4. 

The only changes in the computer utilizations were ir. 
magnitude, and those changes were linear with respect to 
the number of nodes. Note, however, that it is also 
assumed that the network resources also increase as the 
number of nodes increase. Under the wound-wait simula¬ 
tion, for example, with 2 nodes the maximum useful utili¬ 
zation was 30,119 time units; with 4 nodes, ‘39,705 time 
units, with 6 nodes, 90,472 time units, while with 8 
nodes, 120,327 time units were used ir. process i r g transac¬ 
tions. 

The average resporse time, on the other hard, lid nc-t. 
vary as the number of nodes changed. 
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4.3.2. Cl^ass 2 Tra nsactions 

Linearity in computer utilization as a function of 
the number of nodes was also observed for class 2 type 
transactions. The USEFULIO's, USEFULCPU's and average 
response time for the decentralized concurrency control 
algorithms were slightly better than those measurements 
for the primary site with 2, 4, 6 or 8 nodes in the com¬ 
puter network. 

The cost of locking; with the many small transactions 
and the random placement of locks assumption, is, of 
course, much greater than with the class 1 transactions. 
This cost also increased linearly with the number of nodes 
and was practically the same for all four algorithms at 
the optimum granularity. The lock costs for the primary 
site 1 model are shown in Table 3-10: 

The time units per node remained relatively constant. 
However, for the decentralized concurrency control algo¬ 
rithms, the time units used for locking were distributed 
among all of the nodes. In the primary site models all of 

Table 3-10: Time Units Spent Locking 


No. of Nodes 

Total Time Units 

Time Ur its Der Node 

2 

360 8 

". 17’0'i 

4 

676 3 

1691 

6 

10010 

1673 

8 

13300 

1663 




the time units were used for locking at ore node. Thus, 
at the primary site with S nodes in the network, 13,80° 
out of 20,000 available time units were used for locking. 

This increasing overhead for locking at ore node has 
two implications. First, transactions which use the pri¬ 
mary site for data access will receive much poorer service 
than the other nodes. In. fact, it may be necessary to 
reduce the transaction processing load at the primary site 
node. Second, the primary site can become saturated just 
managing locks. With class 2 transactions and the locking 
overhead rate assumed in these experiments, an extrapola¬ 
tion shows that the primary site will saturate if there 
are 12 nodes in the network. Note that the primary site 
also has to handle a disproportiorate share of the mes¬ 
sages. The time units used for handling lock messages 
(MFSCPU) at the primary site should al so be it.ludei it 
looking at primary site saturation. An extrapolation, of 
the total overhead (LOCKCPU + MESCP'U) shows that, the pri¬ 
mary site would saturate with only 11 nodes ii the r ef- 
work. 

For the class 1 transactions, on the other hr 1 , each 
transaction, required much less locking overhead du^ to the 
well-placed lock assumption. Under those assimnt i^r r, , the 
primary site would not bottler,eck until 83 nodes were ir 


the network. 
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4.4. Percent of' Distr ibu ted Transactio ns 

In the previous simulation runs, ten percent of the 
transactions were assumed to be distributed, while the 
other transactions required processing at the local nodes. 
In this section, the effects of varying that percentage on 
the optimum granularity and choice of concurrency control 
algorithms are examined. Experiments were run with values 
of 0, 10, 26, 50, >5, and 100 for the percentage of dis¬ 
tributed transactions parameter (PREDIST). The results 
are presented for both class 1 and class 2 transactions. 

4.4-1. Cl§ss 1 Transa cti ons 

Changes in the percentage of distributed class 1 
transactions affected the optimum granularities dif¬ 
ferently for the different concurrency control algorithms. 
In addition, as that percentage increased, the choice of a 
'best' algorithm for class 1 transactions became clearer. 

The results of the simulation experiments, varying 
the PREDIST parameter, are broken into the following four 
parts. First the effects of the locking granularities on 
the four models are discussed. Next the four models are 
compared, choosing the optimal granularity for each model 
for each setting of the PREDIST parameter. Third, the 
four models are compared under alternate network 
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assumptions. in the final set of exnerimerts , some- mes¬ 
sages useful in terms of crash recovery were added to the 
primary site model. 

E ffect s of Lockitg Granulari ty 

With any of the four concurrency control algorithms, 
if 0% of the transactions were distributed (all transac¬ 
tions are local), the maximum useful computer utilization 
occurred with from 50 to 500 lockable granules. These 
results were similar to the centralized database case in 
Chapter 2. 

The optimum locking granularity for three of the four 
concurrency algorithms changed as the percentage of dis¬ 
tributed transactions increased. With the primary site 2 
model, however, the maximum useful computer utiliz.atior 
occurred at or near 500 granules. 

For example, in figure 3-8, the shapes of the useful 
1/0 curves versus the number of locks are very similar 
when either 10% or 75% of the tran.sactiot s are distri¬ 
buted. For the other three models, 75% distributed tran¬ 
saction curves were skewed to the right when compared t 
the 10% curves. 

The difference between the models is that u the pri¬ 
mary site 2 model, no transactions hold locks at ere node 











while waiting Tor locks at at other rode. As the porc-er. tnge 
of distributed transactions increased, there was an 
increase in the number of transactions which hold leeks at 
the other nodes in the other models. Lower granularity 
increased the number of incidences of this condition and 
hence adversely affected the performance of those algo¬ 
rithms . 

The effects of varying the granularity ar.d the per¬ 
centage of distributed transactions or the decentralized 
algorithms was even, more dramatic. For these algorithms, 
a granularity from 1000 up to 5000 locks at each node was 
required to orcduce the maximum computer utilization as 
the percentage of distributed transactions increased 
beyond 50%. 

The need for finer granularity in these cases was 
caused by two effects. First, as already mentiored, trnr - 
sactions hold locks at one node while waiting for locks at 
a second node. The second factor affecting the granular¬ 
ity in these models was that with coarse granularity mi a 
high percentage of distributed transactiors, mote transac¬ 
tions had to be restarted. 



4.R.I.?. Model_ Comparisor s 

Figure 3-9 shows the effects op the useful I/O and 
the average response time of the percent of distributed 
transactions for each of the four concurrency control 
algorithms. (For each percentage, and for each algorithm, 
the best useful I/O and average response time regardless 
of granularity was plotted.) 

The 'dish' shaped curves for USEFULIO were surpris¬ 
ing. As the percentage of distributed transactions was 
increased up to 50%, all four models showed decreases in 
useful computer utilization due to the additional overhead 
(message handling and locking) required to run distributed 
transactions. However, as the percentage increased beyond 
75%, the useful computer utilization significantly 
increased . 

That increase was due to two factors. First, the 
number transactions running at each node was greatly 
increased. For example, when all of the transactions were 
distributed, NHODFS * MTRAN (60 in the simulation runs) 
parts of transactions were active at each node. Second, 
the average transaction size at each node was smaller as 
more and more transactions were distributed. 

The simulation parameters were modified to keep the 
number and sizes of active transactions at each node con- 



Of distributed transactions 

(a) 



Figaro .-J: Class 1 Transaction 
In I i n i t r !>«ini1w i ^ 
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stant as the percentage of distributed transactions 
increased. Only when both parameters were held fixed did 
the 'dish' shaped curves disaopear. When only ore of the 
parameters (NTRAN or AMEAN-BMEAN) were held constant, hav¬ 
ing all transactions distributed produced more useful I/O 
(and CPU) than when, only 50% of the transactions were dis- 
tributed . 

The average response time curves also demonstrated 
dish shaped curves. In almost all cases, the second pri¬ 
mary site model (PS2), produced the best average response 
time of the four models. The holding of locks at one node 
while waiting for locks at another was quite detrimental 
to the throughput of the system and occurred with increas¬ 
ing frequency in the other three models as the percentage 
of distributed transactions increased. 

When fewer than half of the transactions were non¬ 
local the SNOOP and PS2 models produced about equal useful 
I/O and average response times and were slightly better 
than the other two models. However, when more than half 
of the transactions were non-local, the primary site 2 
model produced sigrificantly better results than the other 


three models. 
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K 3. Limited Bardwiit.h 

The above observations change if a lower network 
bandwidth was assumed. All four concurrency cot trol simu¬ 
lations were rerun , varying the percentage of distributed 
transactions with a message bandwidth of 6. This simu¬ 
lates an environment where only six messages can be active 
in the Network one at a time. The tests included locking 
granularities of 500, 1000, 2500 and 5000 locks at each 
node. Additional values for the PERDIST parameter were 
also tested and included 30, 35, 40 and 45 percent. The 
results are shown ir. Figure 3-10. 

With fewer than 40? of the transactions being non¬ 
local, the global deadlock detector algorithm produced 
more useful I/C utilization than the other algorithms. 
When 45? or more of the transactions were distributed, the 
primary site 2 model again produced better results. Ir: 
these cases, the extra two messages for locking were rot. 
that significant; a distributed transactior rnmiirod at 
least 2 * NSLAVFS messages anvwav. 

Note also that the 'dish' shape curves for 'if.KFUt. 1 "> 
have practically disappeared with a limited bandwidth net¬ 
work. In these cases the extra network delay overhead 
caused by an increased PREDICT parameter more than, offset 
the increases in tr an sac t, i or parallelism. 






SNOOP 
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4 • 4 • 2 • ii • A1. ter rat" Primary 5 i t <• Model 

Those differences between the SNOOP nr.d P.models 
would be even less, if the primary site models required 
the ’release lock’ messar.es to he sent to the SLAVES. In 
many database management systems, trarsactior s might be 
backed out due to system crashes, changes in a user’s mind 
and a variety of other reasons. For these reasors, it may 
be desirable to have SLAVES wait until the transact lot has 
completed at all nodes before ’committii.fi’ any updates. 
In these types of database management svstems, ’all dor o’ 
messages similar to the ’release locks’ messages must be 
sent to the SLAVES ever: with the primary site cor c-urrcr ey 
control . 

The primary site ? model was modified to note • 1 . 
send "all done" messages at the end of each distri but ••• ; 
transaction. With that modification and the limit.."! 
bandwidth network, the primary site ? model actually pro¬ 
duced slightly less useful computer utilizatior th.ar th" 
SNOOP model, regardless of the peri. er. tag'* of d i : -r >■ : n-r • > i 
transact ions. 

4.4.?. Cl^ss ? Transactions 

With class ? trarsactiors, the fires*, gr an u 1 ar i t v was 
optimal, regardless of the percentage of distributed 




transactions. Furthermore, the performance of the con¬ 
currency control algorithms also changed consistently as 
the percentage of distributed transactions increased. 

Figure 3-11(a) shows the USEFULIO for the four algo¬ 
rithms as that percentage increased. The utilization with 
the decentralized algorithms was affected very little by 
the increase in non-local transactions. Again, a slight 
increase in useful computer utilization was realized due 
to the increased distribution of transaction processing. 

In the primary site algorithms, on the other hand, 
the overall computer utilization decreased as the percen¬ 
tage of non-local transactions increased. The decrease 
was most dramatic between 25 and 75 percent. 

The same advantage for the decentralized algorithms 
over the primary site algorithm appeared in the average 
response time, as shown in figure 3—11Cb). For all four 
algorithms the response times increase as the percentage 
of distributed transactions increased. However, the 
increase was much less for the decentralized concurrency 
control algorithms than for the primary site concurrency 
control algorithms. 

Two factors caused the dramatic difference between 
the primary site and decentralized models for class 2 
transactions: the transactions were all small and the 
primary site crea.ted a bottleneck. 




Average response time 


Percent of non-locol transactions 

(a) 



(b) 

Figure 3-11: Class 2 Tr.m m< t i ■ :.s 
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The transactions of class 2 were all small and the 
results in Figure 3-11 were for the finest granularity. 
Under those conditions, the probability of success on a 
lock request was extremely high, which considerably 
reduced the advantage that the primary site 2 model exhi¬ 
bited for class 1 type transactions. 

The second factor which affected the performance of 
the concurrency control algorithms was the bottleneck at 
the primary site. Over 7,000 time units out of a possible 
20,000 were used for locking at the primary site when all 
of the transactions were non-local. Moreover, all tran¬ 
sactions required some database processing at that primary 
site and were thus all delayed by the locking overhead. 
This bottleneck became increasingly worse as the percen¬ 
tage of distributed transactions increased. 

One solution to the bottleneck problem would be to 
offload the primary site concurrency control to a separate 
processor. The primary site 2 simulation was modified to 
test this strategy. 

Two sets of experiments were run. In the first set, 
the workload and network parameters remained the same and 
the concurrency control was off-loaded to a 'seventh' 
node. In these experiments, the primary site model pro¬ 
duced USEFULI0 and average response times very similar to 
the decentralized control algorithm results shown in 




figure 3-11. In fact, the primary site models produced 
slightly better results than the decentralized models when 
the PREDIST parameter was greater than 50%. 

In the second set of experiments, the 6-node data¬ 
base, granules and transactions were distributed on a 5- 
node network with a sixth node being used only for the 
concurrency control . The results were again similar to 
those in figure 3-11 for the decentralized models. How¬ 
ever, in these experiments the modified primary site 
models produced slightly worse results than the decentral¬ 
ized models. 

These two results suggest that a proper database 
design which ' lowered the load at the primary site could 
perform equally as well as the decentralized algorithms. 

The PREDIST simulation experiments for class tran¬ 
sactions were repeated with a limited bandwidth n«‘ i w a !■: . 
In these experiments, the primary site models were host if 
more than 50% of the transactions were dirtribided . Is 
those cases, the primary site models actually sent fewer 
locking messages than the decentralized algor i t hmr,. 

£. 5 . N e twor k Par am> t <• r :■ 

In this section , the »•«•; <i 11 r of v: rvi r r f i v • - < t w • - 
input parameters ar< r> q .r led . I r * j : . v i.-.u- runs : » <• 
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MESRATE, or the length of time it takes to send a message, 
was fixed at 3 simulation time units. The MESBDWT, or 
number of simultaneously active messages, was effectively 
set to oo, by setting the MESBDWT parameter to 1000. 

The data transfer parameters, PRETRAN and PREDATT, 
were also fixed in all of the previous simulation experi¬ 
ments. In those experiments JJ0 5E (PRETRAN) of the distri¬ 
buted transactions sent 25% (PREDATT) of their entities to 
other nodes. The DATARATE parameter was set to .05, which 
determined how long it took to send data entities across 
the network. 

One other network parameter, the MESSCPURATE, while 
not affecting the network directly, did affect tie message 
or network overhead required at each node. For all of the 
previous experiments, a message CPU rate of .01 (300 
microseconds) was assumed. 

Simulations were run with MESRATES of 1 (30 msecs), 3 
(90 msecs) and 10 (300 msecs, similar to the ARPANET). 
The simulations were also run with MESBDWT of 100, 50, 10 
and 6. The DATARATE ex periments included, 0.05, 0.1, 0.25 
and 0.5. The message CPU rate parameter was set to .01 
(300 microseconds), 0.05 (1.5 msecs), 0.1 (7 msecs) and 
0.3 (9 msec s). 

Class 2 transactions required much greater use of the 
network resources than class 1 transactions. Thus 
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variations in the network parameters had a much greater 
effect on class 2 transactions. 

4.5.K Class _1_ Transactions 

The significant effects of lowering the bandwidth and 
varying the percentage of distributed transactions have 
already been reported in section 4.5. Varying the MES- 
RATE, MESBDWT and MESCPURATE parameters had little effect 
on the other observations reported. 

The effects of varying the message rate parameter 
were slight. The results with message rates of 1 and 3 
were almost identical for all four concurrency control 
algorithms. A MESRATE of 10 resulted in about a 5% 
decrease in useful computer utilization for the primary 
site models and almost no change in the useful utilization 
for the distributed concurrency control models. 

MESBDWT settings of 100 and 50 produced useful com¬ 
puter utilizations and average response time identical to 
the infinite setting 1000 previously used. Slight drops 
in the useful 1/0 and CPU utilizations were realized with 
message bandwidths of 10 and 6. The drops with a message 
bandwidth of 10, however, were 1 ess than 1 % and not con¬ 
sidered significant. 
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A message bandwidth of 6 did produce more noticeable 
reductions in the useful I/O and CPU utilizations. The 
drops in useful utilization were only about 2-3? with the 
primary site and SNOOP models. The wound-wait model, on 
the other hand, realized a drop of almost 7?. Although 
the primary site models sent more lock messages, they were 
mainly sent one message at a time. A wound or kill, how¬ 
ever, resulted in NSLAVE messages being sent, or broadcast 
over the network. These "bursts" of messages were 
effected more by the lower bandwidth than the greater 
number of individual messages in the primary site models. 
In the SNOOP model, on the other hand, a conflict only 
required 1 message. A kill still required NSLAVE mes¬ 
sages, but occurred very rarely. 

The change of the DATARATE parameter had little 
effect on class 2 transactions. When the DATARATE was .5 
and all of a distribute transaction's entities were sent 
across the network, a decrease in the computer utilization 
of only about 7? was realized. 

With an extremely fast DATARATE parameter (.05 as in 
the canonical scenarios), changes in the number of tran¬ 
sactions which transferred data, or the amount of data 
they transferred produced curves almost identical to those 
shown in figures 3-^, 3-5 and 3-6, :;r.d arc not repeated 
here. A slight drop in useful I/O and CPU time was 
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observed as the amount of data transferred increased for 
both classes of transactions and for each of the con¬ 
currency control algorithms. However, even if all of the 
distributed transactions transfer all of their data, the 
decrease was less than 3%- 

Note that these results do not imply that data 
transferred is not an important parameter in a distributed 
database. In the models considered here, data transfer 
resulted in a waiting time for that transfer to complete. 
Under these assumptions, no additional I/O or CPU 
resources were used in transferring data; it was assumed 
that use of these resources is already included in tran¬ 
saction processing. Furthermore, with the fast DATARATE 
assumed, even a transaction accessing 500 entities would 
wait on the transaction wait queue for only 25 time units. 

When the DATARATE was increased from .05 to .5, and 
the PRETRAN and PREDATT parameters were varied, a larger 
drop in useful CPU and I/O utilization was observed. At 
the optimum granularity, a drop of almost 7 % in computer 
utilization was realized. In these cases, the larger 
transactions might wait on the CPU queues for ? r 0 time 
units, a significant portion of their lifetimes. 

Changes in the i CRATE parameter had the greatest 
effect on the useful computer util: zat. i • r output pen ame- 
ters. In the primary rile model: , a dr err nr e of nlmo-t r) 7 
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was realized when the message rate was increased to .3 
(almost 9 msecs). With that same message rate, the useful 
computer utilization only dropped by about 4 % in the 
decentralized models. 

In class 1 transactions, the critical resources ar 
the I/O and CPU resources at the nodes and not the network 
resources. Thus the heavy message traffic of the primary 
site models is impacted much more by the message CPU rate 
than the other network parameters. 

5.2. Class 2 Transactions 

The MESRATE, ME5CPURATE, MESBDWT, and DATARATE param¬ 
eters were also varied for class 2 transactions. Changes 
in the first three parameters affected the performance of 
all four concurrency control algorithms. The DATARATE 
parameter had practically no effect on the processing of 
class 2 transactions. 

The USEFULIC end the average response time (in 
parenthesis) is given in Table 3-11 for each of the four 
concurrency control algorithms. In the first set, the 
MESRATE parameter was varied while the KESCPURATE and 
MESI'DV.'T were fixed at .01 and 1000 respectively. As the 
message rate increases, the gap between the primary site 
and decentralized control models widened. 
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Table 3-11: Effects of Network Parameters 
PS 1 PS2 WW SNOOP 


MESRATE 

1 

94994(63) 

94720(63) 

95839(61 ) 

97037(62) 

3 

93996(64) 

93319(64) 

97134(61) 

96204(62) 

10 

87998(67) 

88078(67) 

96037(63 ) 

96875(62) 

MESCPURATE 
.01 93996(64) 

93319(64) 

97145(65) 

96204(62) 

.05 

88953(67) 

88767(68) 

95048(63 ) 

94710 (64 ) 

. 1 

83273(72 ) 

83086(73) 

92394(65) 

91860(65) 

.3 

58676(102) 

58372(102) 

83313(72 ) 

82690(73) 

MESOULP 

1000-50 

93996(64) 

93319(64) 

97145(6 1 ) 

96204(62) 

10 

82804(72) 

83234(72) 

96827(6?) 

96979(62) 

6 

55200(108) 

55692(108) 

95948(63) 

96242(62) 


A more dramatic change occurred when the message CPU 
rate was varied. During these experiments, the MESRATE 
and MESBDWT were fixed at 3 and 1000 respectively. With a 
3 millisecond cost (MESCPURATE = .1) for sending a mes¬ 
sage, the primary site models produced only 89% of the 
useful computer utilization that was realized with the 
decentralized concurrency control algorithms. With a 9 
msec message rate (MESCPURATE = .3) this percentage drops 
to 72%. 


Similarly, a dramatic change in USF'F'JLIO and response 
time for the primary site models was realized as the mes¬ 
sage bandwidth was restricted. For these experiments, the 
message rate and message CPU rate parameters were fixed at 
3 and .01 respectively. Note that while the performance 
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of the primary site models was heavily affected by the 
restricted bandwidth, the decentralized models were hardly 
affected at all. This result is due to the fact that with 
the primary site models, almost 40,000 more messages were 
sent than with the decentralized algorithms. 

Variations in the DATARATE, PRETRAN and PREDATT 
parameters had little or no effect on the performance of 
the four concurrency control algorithms. Class 2 transac¬ 
tions were all small. Thus any wait on the data transmis¬ 
sion queue was also small even if all of the distributed 
transactions transferred all of their data. 

As expected, the performance of a primary site con¬ 
currency control algorithm deteriorated as restrictions 
were placed on the network. The effect of the restric¬ 
tions on the wound-wait and SNOOP algorithms was much 
smaller. 

4.6. Canonical Scenario Revisited 


In section 4.1, the effects of the different con¬ 
currency control algorithms on computer utilization and 
average response times with two different classes of tran¬ 
sactions were presented. In those experiments a very 
fast, low overhead and high bandwidth network was assumed. 
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Subsets of those eases were rerun under alternate 
network assumptions. For the results presented in Figure 
3-12, the MESRATE was assumed to be 10 simulation time 
units or about .3 seconds. The MESBPWT parameter was set 
to 6, while the MESCPURATE was set to .1, simulating a 
cost of about 3 msecs to handle a message at a node. 
These settings roughly resemble the ARPANET parameters. 
Note that the simulations were not run for all of the 
granularities. 

In section -h. 1 for class 1 transactions with finer 
granularities, no one concurrency control algorithm seemed 
dominant. Figure 3-12 shows, on the other hand, that the 
decentralized algorithms, the wound-wait or SNOOP, produce 
significantly better machine utilization than the primary 
site models. The drop of about 9% realized with the pri¬ 
mary site models, when compared to the decentralized 
models, is consistent with the drop observed in section 
4.6, when only one of the network parameters was varied. 

The advantage of the decentralized algorithms for 
class 1 type transactions shown in section 4 . 1 became oven 
more apparent when a slower network was assumed. Note, 
however , that under the given network parameter the useful 
computer utilizations for even the decentralized algo¬ 
rithms were much lower than with the original ret work 
parameters. Thus, regard loss of the concurrent y control 
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algorithm, a 'distributed database where nil transactions 
are very small is perhaps not suitable for a slow computer 
networ k. 


5. CONCLUSIONS 

As with the centralized database concurrency control, 
the algorithms and parameters of the concurrency control 
for a distributed database are also application and system 
dependent. In this section the major conclusions on the 
locking granularity, the algorithms for class 1 and class 
2 type transactions are reviewed. 

5.U Locking Granularity 

In general, a finer granularity is required for lock¬ 
ing in a distributed database than in a centralized data¬ 
base. However, if the locks are well-placed with respect 
to the accessing transactions, the finest granularity is 
still not worth the additional concurrency produced. 

The need for finer granularity in a distributed data¬ 
base was caused by one major factor: transactions held 
locks at one node while waiting for locks at another node. 
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When that condition was avoided with the PS2 model, much 
coarser granularity was acceptable. 

Even that model, however, required slightly less 
coarse granularity than was required for a centralized 
database under the same assumptions. In the centralized 
database, 10 to 100 granules produced the maximum useful 
computer utilization under the well-placed lock assump¬ 
tions. In the PS2 distributed database, 100 to 1000 
granules are required. In the PS2 model and very coarse 
granularity, many distributed transactions have to release 
and rerequest locks at a low number nodes. The additional 
locking overhead makes coarse granularity unacceptable. 

5.2. Class 2 Transactions 

If the number c*f distributed transactions is low 
(£10%) and the network is considered lightly loaded, the 
performance of all four concurrency control algorithms was 
very similar for class 1 transactions. 

As the percentage of distributed transactions 
increase, the primary site 2 model produces better com¬ 
puter utilization and average response times than either 
of the decentralized models. In these cases, the extra 
two messages required in the primary site model represent 
a lower percentage of overhead since the transactions will 
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be sending at least 2 * NSLAVE messages anyway. Moreover, 
this overhead is more than offset by the ability to avoid 
inactive nodes. 

When the bandwidth of the network is lowered and the 
number of distributed transactions is low, however, the 
decentralized concurrency control models produce better 
computer utilization and response time than the primary 
site models. In these cases, the primary site lock mes¬ 
sage overhead interferes with the normal transaction pro¬ 
cessing . 

The above two conclusions come into conflict as the 
percentage of distributed transactions increases and a low 
bandwidth network is assumed. The simulation results 
indicate that with a low bandwidth network, the SNOOP dis¬ 
tributed concurrency control algorithm is best when less 
than 45% of the transactions are distributed. When more 
than 45% of the transactions are distributed, the primary 
site 2 model is preferred. 

When the percentage of distributed transactions is 
less than 10%, the SNOOP and wound-wait algorithms perform 
equally well. However, as that percentage increases, the 
SNOOP model results in better performance than the wound- 
wait model. As expected in these cases, the percentage of 
conflicts increases and has a more adverse effect on the 
wound-wait algorithm. 
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5 . 3- Class 2 Transactions 

Under the class 2 transaction assumption, all of the 
transactions are small and randomly access entities in the 
database. In these cases, the decentralized concurrency 
control models consistently produce better response times 
and useful I/O and CPU utilization than the primary site 
models. With extremely small transactions, the extra mes¬ 
sages in the primary site models represent a significant 
delay factor. Furthermore, the small transactions make 
the probability of conflict and restart very low with the 
dectralized concurrency control algorithms. 

Also, with only small transactions and random lock 
placement assumptions, the locking overhead is a signifi¬ 
cant factor. When all of this overhead is concentrated at 
one site, that site can bottleneck as either the number of 
sites in the network or the percentage of distributed 
transactions increase. 

The above observations for class 2 transactions hold 
even under optimistic network conditions. As the network 
parameters become restrictive, the advantages of the 
decentralized concurrency control become even more evi¬ 
dent . 

The wound-wait and SNOOP concurrency control models 
produced extremely similar results for class 2 transac- 
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tlons. This similarity was due to two factors. First, 
the small transactions are involved in very few conflicts 
and thus the probability of a transaction blocking and 
being blocked by an older distributed transaction is 
extremely small. The second factor is that a transaction 
is much more likely to be blocked by an older transaction 
(in which case, no wound or kill takes place) since the 
individual sites operate with a preclaim locking strategy. 




CHAPTER H 

CONCLUSIONS 


The major goal of this thesis was to examine the 
effects of concurrency control on the performances of 
database management systems. The effects of concurrency 
control on performance are dependent on two conflicting 
factors. On the other hand, the database system perfor¬ 
mance can be enhanced by allowing concurrent users simul¬ 
taneous access to the database. Both the useful computer 
utilization and the average response time can be improved 
by supporting a multiple user environment. 

On the other hand, the database system performance 
might be degraded due to extensive concurrency control 
overhead. The concurrency control overhead is due to the 
computer resources utilized in some type of "locking". 
The "locking" is used to prevent one user of the database 
from interfering with the processing of another user. 

In the first section of this chapter, the major con¬ 
clusions from Chapters 2 and 3 are reviewed. In the next 
section the applications of these conclusions to other 
concurrency control implementations are projected and 
several areas of further research are suggested. 
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SUMMARY OF PREVIOUS CONCLUSIONS 

Simulation models were used to study the performance 
effects of concurrency control in both centralized and 
distributed databases. 

1 - 1 - CENTRALIZED DATABASES 

In a centralized database, all database activity, 
including concurrency control, are processed on a single 
computer system. A simulation model was used to determine 
the optimum granularity for locking, the effects of a 
variety of workload and system characteristics, the 
effects of a lock hierarchy, and the effects of a "pre¬ 
claim" versus a "claim as needed" locking strategy. 

The overall conclusions on locking granularity are 
application dependent as shown in Table 4-1. 

Table 4-1 Locking Granularity 

small large mixed sized 

Transactions Transactions Transactions 

Coarse gran. Coarse gran. Coarse gran. 

Fine gran. Coarse Gran. Lock Hierarchy 

with Fire gran. 


Wei1-placed 

Random 

placement 
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In many cases coarse granularity, such as file or 
relation locking, is preferred. However, if random lock 
placement is assumed and all of the transactions are 
small, the coarse granularity is unacceptable and fine 
granularity locking must be implemented. 

If random lock placement is assumed and a variety of 
different sized transactions are present in the workload, 
a lock hierarchy should be used. In such a hierarchy, 
some large transactions can lock large granules, while 
other small transactions lock much finer granules. If a 
transaction were to set more than 1 % of the smaller locks 
under any one large lock, it would be more efficient for 
that transaction to simply set the one large lock. 

In a preclaim locking strategy, a transaction 
acquires all of its locks at the beginning of the transac¬ 
tion. In a claim as needed locking strategy, the locks 
are acquired as the respective parts of the database need 
to be accessed. With a few exceptiors, the preclaim stra¬ 
tegy produced better machine utilization than the claim as 
needed model. However, the above conclusions on locking 
granularity and a lock hierarchy hold, regardless of 
whether a proclaim or claim as needed strategy is used. 






].?. Distributed Database s 

In a distributed database, the database activity, 
including the concurrency control, are processed on 
several computer systems connected by a network. Four 
concurrency control algorithms were simulated in order to 
study their performance effects under a variety of work¬ 
load and network conditions. 

Two of the algorithms simulated involved a central¬ 
ized concurrency control where locking for the entire- 
database was controlled at one primary site in the net¬ 
work. In the "primary site 1" model, transactions acquire 
the locks needed at each node or site in some fixed order. 
If the locks for one node are denied, the "blocked" tran¬ 
saction waits for those locks while holding locks on lower 
ordered nodes. 

In the alternate centralized control model, the "pri¬ 
mary site 2" model, the locks needed at each node arc 
again acquired in some fixed order. However, in thin, 
case, if the locks for one node are denied, the 'Mocked' 
transaction releases all currently held locks while- writ¬ 
ing for access to the locked granules. 

The other two algorithms simulated involved decen¬ 
tralized concurrency control where locking for the portion 
of the database at each node was controlled at that node. 
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In the "wound-wait" model, deadlock is prevented by 
"wounding" any "young" transaction that dares to block an 
"older" transaction. The wound is transferred to all 
sites where the wounded transaction is active. If a 
wounded transaction is blocked at any site by an "older" 
transaction, the wounded transaction releases its locks at 
each site and is then restarted. 

In the other decentralized control algorithm, 
deadlocks are resolved by a global deadlock detector, or 
"SNOOP". If a deadlock exists, a transaction is picked 
which also releases its locks at each site and is then 
restarted . 

Which model is best in terms of its effect on the 
distributed database system performance is also applica¬ 
tion dependent as shown in Table 4-2. Class 1 transac¬ 
tions refer to a workload environment where the locks are 
assumed to be well-placed with respect to the accessing 
transactions and that those transactions are of mixed 
sizes. Class 2 transactions refer to workloads where all 
of the transactions are small and random placement of 
locks is assumed . 

In some cases, it appears that the concurrency con¬ 
trol mechanism is not a significant factor in the database 
system performance. For class 2 transactions, additional 


Table 4-2: Concurrency Control Models 

C1 a ss 1 Class? 

Transactions Transactions 

Fast Net. Primary Site or Primary Site or 

Most trans. Decentralized Decentralized 

local 

Slow Net. SNOOP Decentralized 

Most trans. 

local 

Fast Net. Primary Site 2 Decentralized 

Most trans. 

non-local 

Slow Net. Primary Site 2 Primary Site 

Most trans. 

non-local 

simulation runs showed that the preference for decentral¬ 
ized concurrency control could be offset by reducing the 
database load at the primary site. Thus in these cases, 
the choice of concurrency control algorithm may again not 
be significant. 

For class 1 transactions, when most of the transac¬ 
tions only required local processing and a slower, lower 
bandwidth network is assumed, the f.NDOF algorithm ipre¬ 
ferred. In this case, the SNOCi' model was favored St .a::. 
of the lower number of mess,ages required. 

Also for class 1 t ? ansae lions., if most of ire • ran- 
sactions are non-local or distributed, the primary site 
model is preferred. The advantage of the primary site 
model is that only in that model does, a Iranr.i.-t i .a. 




release locks at all other nodes while waiting for locks 
at one node. In the other three models, it is possible 
for a transaction to hold locks at one node while waiting 
for locks at another node. 

Another factor which favors the primary site 2 model 
over the decentralized models when most transactions are 
distributed, is that in those cases, the primary site 
model no longer produces heavier message traffic. 

The distributed database simulations indicated that 
some of the coarse granularity conclusions for the cen¬ 
tralized database do not hold for the distributed data¬ 
base. However, under the well-placed lock assumptions, 
the finest granularity is still worse than a medium granu¬ 
larity concurrency control. 

Z- future DIRECTIONS 

The results of the simulation studies suggest several 
areas for future study. Two such areas would be to extend 
the lock hierarchy and the claim as needed locking models 
to a distributed database. Another study would be to 
investigate the multiple copy problem in the distributed 
database model. The results of the simulations in this 
study do, however, provide some insights in each of these 
areas. 
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For the centralized database, the conclusion was 
reached that if the locks are well-placed, coarse granu¬ 
larity is preferred and a lock hierarchy is thus not bene¬ 
ficial. In those cases, it was mere efficient to just use 
one level of coarse locking (10 to 100 locks). In the 
distributed database cases, finer granularity (500 to 1000 
locks) is required even if well-placed locks are assumed. 
A lock hierarchy in that granularity range was beneficial. 
Thus a lock hierarchy at each node for a distributed data¬ 
base might be more useful than in a centralized database. 
This projection could be verified by simple extensions to 
the distributed database simulations similar to the exten¬ 
sion in chapter 2. 

A claim as needed locking strategy may be required if 
the entities to be accessed, iind hence the granules to be 
locked, are dependent upon the values of entities previ¬ 
ously accessed. With a claim as needed locking strategy 
in a distributed database, the primary site models might 
require two messages for every lock set. In addition, 
with claim as needed locking, the primary site models 
would also have to prevent or detect dead 1 'ek and thus 
lose one of their advantages over the decentralized 
models. Therefore, for claim as needed locking, the pri¬ 


mary site models would probably not be aero pint 1 «- 



The comparison of the two decentralized concurrency 
control algorithms might be affected by a claim as needed 
locking strategy. With the preclaim locking strategy and 
the wound-wait model, relatively few transactions were 
wounded since there was a high probability that a blocking 
transaction was older than the blocked transaction. With 
a claim as needed locking strategy, however, a transaction 
would request locks at several different instances during 
its lifetime. Thus, the probability of being blocked by a 
younger transaction would increase. Consequently, the 
global deadlock detecter or SNOOP algorithm would probably 
be better than the wound-wait algorithm in a claim as 
needed locking environment. Simple simulation extensions 
could also be used to test that hypothesis. 

The multiple copy concurrency problem was discussed 
in Chapter 1. In a distributed database, it is sometimes 
advantageous to replicate parts of the database at several 
of the nodes in the network. The multiple copy con¬ 
currency problem is to ensure that the replicated copies 
are kept mutually consistent or identical during simul¬ 
taneous user updates. 

The four distributed database concurrency control 
simulations could be applied to the multiple copy problem 
as follows. Assume that the entire database is replicated 
at each node. Gone transactions are 'read-only' t.ransac- 





tions and just need to access the data at one rode. These 
transactions can be considered the local transactions in 
the simulations. The 'write' transaction, on the other 
hand, must cause activity at each node and thus may be 
considered the distributed transactions. 

In this interpretation, the PREDIST parameter would 
represent the percentage of update trar. sactions. Under 
the above interpretation, the conclusion summarized in 
Table 4-2 can be applied to the multiple copy problem. If 
the database is dominated by updates (i.e. most transac¬ 
tions non-local) and the updates are relatively large and 
sequential in nature (i.e. Class 1 transactions), a pri¬ 
mary site concurrency control is suggested. Thus all 
transactions would first acquire locks at a 'primary copy' 
of the data. 

However, if all of the updates are small and random 
in nature (i.e. Class 2 transactions) or most of the 
transactions are 'read-only' with respect to this database 
portion (i.e. local transactions) then a decentralized 
concurrency control is suggested (or is at least accept¬ 
able). In a decentralized concurrency control, the 
updates would request locks at each rode and proceed with 
the updates. However, the updates would have to to 
prepared to be rolled back due to conflicts with other 
updates. 
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However, the above analysis is an over simplification 
of the multiple copy problem in a distributed database. 
One over simplification is that other concurrency control 
solutions exist to the multiple copy problems which are 
not directly extendible to the internal database con¬ 
sistency problems. These algorithms must also be compared 
with the simulated algorithms. 

More importantly, the above analysis assumes a fixed 
distribution of the copies in the distributed database. 
In other words, the database is fully replicated and then 
the number of updates and the network parameters are 
varied. But the optimum replication of the data actually 
depends on the proportion of updates and the network 
parameters. In fact the optimum replication of the data 
may be influenced by the multiple copy concurrency con¬ 
trol . 

These analysis deficiencies cannot be over come by 
straightforward extensions to the existing simulation 
models. Instead a more complete model should be developed 
to jointly study the database consistency and multiple 
copy problems. 

In summary, this dissertation provides insights into 
the effects of concurrency control on database system per¬ 
formance under a wide variety of conditions. The results 
of the dissertation can be usc-d to guide concurrency 


■ YjMrrfcktMiiii■ 











REFERENCES 


ALSB76 


ASTR76 


BERN77 


CHAM74 


C0DA71 


Alsberp,, P.A., Belford, G.G., Day, J.D. 
and Grapa, E., "Multi-copy Resiliency 
Techniques", CAC Doc.202, Center for 
Advanced Computation, University of Illi¬ 
nois at Urbana-Champai^n, May 1976. 

Astrahan, M. et.al, "System-R: Relational 
Approach to Database Management," ACM 
Transactions on Data Base Systems, Vol . 1 , 
No.2, June 1976. pp. 96-137 

Bernstein, P.A., Shipman, D.W., Rothnie, 
J.B., and Goodman, N., "The Concurrency 
Control Mechanism of SDD-1: A System for 
Distributed Databases", Technical Report 
CCA-77-09, December 1977. 

Chamberlin, D. et. al, "A Deadlock-Free 
Scheme for Resource L.oekirq in a Data Base 
Envirormert",IBM Research ReDort, San 
Jose, Ca. , Jure, 1979. 

Data Base Task Group of the CODASYL Pro¬ 


gramming l.anquaq" Committee, April, 1971. 


CODA73 C0DASY1. Program ir i* L at. quo T e C '•".'lit * . 

CODASYL COBOL Data Base Faeil ity Pro no so; , 

March 1973. 

C0FF71 Coffman, Jr. E.G., Flphiok, M.J., 

Shoshari, A., "System Deadlocks" Cc m oat i r. r 
Surveys, Vol.3 No. 0 , Jure 1971 no 67-73. 

C0UR71 Courtois, P.J., Heymans, F., and Part ass, 

D.L., "Corcurrer t control with readers ar.d 
writers", Commur icaticr s of t!:e A7”, Vol . 
14 No. 10, October 1971, pp.667-668. 

DEC77 Digital Equipment Corpor itiot , "PbMS-11 

Data Base Administrator's Guide' 1 , Df.C-11- 
ODABA-A-D, 1976. 

DIJK69 Dijkstra, F.W., "Cooneratitq sequential 

processes", In Proqrammirq Lot reoqes. F. 
Genuys, ed ., Academic Press, New Y rk, 
1968, pn./n-n?. 

F.LLI77 Ellis, C.A., "A Robust Algorithm for 

Updating Duel irate Databases", Proceed i t.qs 
of the f’-cpot d Berkelev Workshop ot Distri¬ 
buted Data Mar aq cm or t and Com pit'. or Net¬ 


works, May, 1077, 


Merkelev , 


falifort ia , 




204 


EPST78 


ESWA7* 


FLOR74 


C.ARC7R 


pp. 146-158. 

Epstein, R., Storebraker, M., and Wong, 
E., "Distributed Query Processing in a 
Relational Data Base System”, ACM SIGMOD 
International Conference or. Management of 
Data, Austin, Texas, pp. 169-180. 

Eswaran, K. P., Gray, J. N., Lorie, R. A., 
Traiger, L. I., "On the Notions of Con¬ 
sistency and Predicate locks in a data 
base System ", Communications of the ACM, 
Vol.19, 1jo.11, November, 1976. pp. 624- 

633. 

Florentin, J.J., "Consistency Auditing of 
Data Bases", The Computer Journal, Vol.17, 
No.1, February, 1974, pp. 52-58. 

Garcia-Molina, >{. , "Performance Comparison 
of Two Updates Algorithms for Distributed 
Databases", Proceedings of the Third 
Rerkelev Workshop on Distributed Data 
Management and Computer Networks, August 
1978, Bar Francisco, Califorria, pp. 108- 


119 . 



GRAP76 


GRAY75 


ORAY76 


GRAY78 


MAWT79 


Grar a . . * • . - 

but' 5 ! .* ■ ' ' i . 

Drivers,-. : • ’ ' ' . • 

Gray , J : ' ' ■ ■ . 'i. !• . 

"Grar-.ul ar 1 1 ■, f .• . Data 

Base" , P r • . ’ : i •’ • •••-•?•*.»», c rrn- 

ip<?ham, Ma. rr . «“* . 

Gray, J . “I., [.'a •* , R . *. . . l '-it. Ill . G . R . 
and Traitor. I. ; " lr a' sr i v of Locks 

and Decrees cf Cl.; r i aa’ , v ;t a Shared 
Data Base.'' Pr^, . IF I? '.urkit Cct feror.co 
on Model 1 i r. of Data Par?** ‘-‘ar sterner t. Sys¬ 
tems, Freud er st ad t, Germany, -January 1976. 
pp. 69S-7?3. 

Gray, J., "Notes on Data Base Operating 
Systems", IBM Research Report, RJ 2188, 
San Jose, California, 197°'. 

Hawthorr e , F . ar.d Stor.ebr nker , M. , "The 

Use of Techno lo".ical Advances to Ft lmi.ee 
Database Mai a.'rmet t System R er f cr: at c c , 
Univei'sitv of Califorria, PlotJ.roi i; r. 
Research Laboratory, FRL Memo M79/1, Janu¬ 


ary, 1979. 








MEW 1.7 7 


KLEI76 


LAMP78 


LRL76 


LRL77 


LBL7R 


206 

Hewlett-Packard Cotporatiot , "IMAGE Refer¬ 
ence Manuel", 1977. 

Klein rock, L., "Queuing Systems", Vo1.2, 
John Wiley and Sons, Publisher, 1976. 

Lamport, L., "Time, Clocks, and the Order¬ 
ing of Everts in a Distributed System", 
Communications of the ACM, Vol.21, No.7, 
July, 1973, pp.558-565. 

Proceedings of the First Berkeley Workshop 
on Distributed Data Management arid Com¬ 
puter Networks, May, 1976, Berkeley, Cali¬ 
fornia . 

Proceedings of the Second Berkeley 
Workshop or Distributed Data Management 
and Computer Networks, May, 1977, Berke¬ 
ley, California. 

Proceedings of the Third Berkeley Workshop 
or: Distributed Data Management and Com¬ 
puter Networks, August, 1978, San Fran¬ 
cisco, Call fort ia . 


iHyjtfrtiltif^iiitliliiirr'l v ni[irtfrgjrti*nrii * x" 





LIPS76 Lipsor , W. and Lapeznk, "!/•:. 

Manual " , Computer Systran fD'sear:-h Sm , 
University of Toronto, Tec hr i. t» 

N o . 9 , A u p u s t, 1 9 7 6 . 

MACR76 Maori, P., "Deadlock Deteeticr and Resolu¬ 

tion in a CODASYL Rased Data Vat a'.e-ten t. 
System," Proc . 1976 ACM-SIG'-’Oi* Cot fer.'-nee 
on Management of data, Vashinptor , P. C., 
June, 1976 dp. 45-50. 

MFNA78 Measce, D. A. and Muntz, R.R., "Loo kit.r at d 

Deadlock Detection in Distributed Data¬ 
bases", Proceedings of the Third n ork°ley 
Workshop or: Distributed Data Mat tap erne: t 
and Computer Networks, August., 1978, San 
Francisco, Cali fort: ia, pp. 21 5-? 32. 

MUNZ77 Munz, R., Kret.z G., "Concurrency i r. Data¬ 

base Systems - A Simulation Study", Free. 
ACM SIGMOD Int^rnatiot a 1 Cor.ferrt ; « or 
Management of Data, To rot. to , Cat ad a , 
Aupust, 1977. np. 111-12D. 

NAKA75 Nakamura, Yoshila, I. arid Hidefumi, K. , "A 

Simulntior rat'd el for a database svstma 


per forman.ee evaluitior", AF 1 PS 


ci' or c e 


208 


RIES77 


RIES79 


RODR76 


R03E77 


Pt'oi ( o.) i r ^ n 1978 N it i oi ,iT Computer Cot fer- 
oree, Vol.MM, May. 1975, Ar.aheim, Califor¬ 
nia, np . 959-906. 

Ries, D. R., Storebraker, M. "Effects of 
Locking Granularity in a Database Manage¬ 
ment System", ACM Transactions on Database 
Systems, Vol.2, No . 3, September, 1977 pp. 
233-296. 

Ries, D.R., Storebraker, M., "Locking 
Granularity Revisited", ACM Transactions 
on Database Systems, Vol.3, No.2, June, 
1979. 

Rodriquez-Rosell , J., "Empirical Data 
Reference Behavior in Data Base Systems" 
Computer, Vol.9, No.11, November 1976 pp 
9 - 13 . 

Roserkrar V? , P.J., Teams, R.E., and Lewis, 
P.M., "A system Level Cor currency Control 
for Distributed Database Systems", 
Proc nod i r. r, s of the Secord Berkeley 
Workshon or Distributed Data Mar-axemen l 
and Computer Networks, '-'av, 1977, Berke¬ 

ley, Califcrria, np. 132-195. 












SP1T76 


STELA 76 


ST0N7*» 


STONY7 


STONY8 



Spitror , J . F. , ”> f t • •* : • ' ' 

of PoI-.j M.ur •• "l ~r t ‘ : : ■ . : 

ACM'/; Atr ual Cc r for or .. <• , ' u -t : . . 

October 1 0 7 6 . r:>. o 8 7 - 0 / . 

Stcart s, R. F. ot <ul , "Coi . urr-.r . 1 

for Data i'T'p System'. - ', l’r a. ' ' 7 • ! ~ ! -' 

Symnosi u*n or ‘-’Mir i • t i r ■"!' f. *:j r> • a * - r : - 

once, October l47 r ’. op. l r '< 

Stor ebraker , M. , "High Lov-l 1: !<■■•! i t v 
Assurance ir. Rolati'. r a] bat j rso 

terns’*, IJr i verst tv of CV: i f.;.rt i a , FT cotr-a? - 
ics Research Laboratory , "one FRL-M•'*78 , 

August., 1 97 U . 

Stor. chr.aker . M. at:<i L-.-umvI I, F. , "A bi s- 
tributed Database Vers i r t of 'ML-;:'"". 
Proceedings of the Seeord Berkeley 

Workshop or Distributed Data v a*- ot. 

arid Cor;»ut «r Let worka , Vav , 1977 . te¬ 

le y , C a 1 i fo r: i , p o . 1 9 - k n> . 

Stor ebr aker , M . , " f ■ i ; urret:. y CL r 1 r . f 

Multiple Ccrf Data it: D i -,tr i bur >• ; 

. it- ore * I r - f tbe Tb i i : • r- 

Workshop or Di st. i- 1 but Put ,i r -i.. ; ..» ; 








210 



and Computer Networks, August, 1978, San 
Francisco, California, pp. 235-298. 

THOM78 Thomas, R.A., "A Solution to the Update 

Problem for Multiple Copy Databases which 
uses Distributed Control", BBN Report 
33^0, July 1978. 

WONG77 Wore,, E., "Retrieving Dispersed Data from 

SDD1: A System for Distributed Data¬ 

bases", Proceedings of the Second Berkeley 
Workshop or: Distributed Data Management 
and Computer Networks, May, 1977, Berke¬ 
ley, California. pp. 217-275. 

YA077 Yao S. B., "Approximating Block Accesses 

in Database Organizations" , Communications 
of the ACM, Vol. 20, No. 4, April 1977, pp 
260 - 261 . 




